fix broken links & typos, run zensical build --strict in CI, use fixed commits for used actions, add Makefile

.github/workflows/docs.yml

@@ -15,15 +15,15 @@ jobs:
       url: ${{ steps.deployment.outputs.page_url }}
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/configure-pages@v6
-      - uses: actions/checkout@v6
-      - uses: actions/setup-python@v6
+      - uses: actions/configure-pages@45bfe0192ca1faeb007ade9deae92b16b8254a0d # v6.0.0
+      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
         with:
           python-version: 3.x
-      - run: pip install zensical
+      - run: pip install -r requirements.txt
       - run: zensical build --clean
-      - uses: actions/upload-pages-artifact@v5
+      - uses: actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9 # v5.0.0
         with:
           path: site
-      - uses: actions/deploy-pages@v5
+      - uses: actions/deploy-pages@cd2ce8fcbc39b97be8ca5fce6e763baed58fa128 # v5.0.0
         id: deployment

.github/workflows/test.yml

@@ -0,0 +1,28 @@
+# documentation: https://help.github.com/en/articles/workflow-syntax-for-github-actions
+name: build documentation
+on: [push, pull_request]
+# Declare default permissions as read only.
+permissions: read-all
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        with:
+          python-version: 3.x
+
+      - name: codespell
+        uses: codespell-project/actions-codespell@8f01853be192eb0f849a5c7d721450e7a467c579 # v2.2
+        with:
+          check_filenames: true
+          skip: '.git'
+          ignore_words_list: 
+
+      - name: install Zensical
+        run: |
+            pip install -r requirements.txt
+            zensical --version
+
+      - name: check build
+        run: make test

Makefile

@@ -0,0 +1,13 @@
+all: build
+
+build:
+	zensical build
+
+deploy:
+	zensical gh-deploy --force
+
+test:
+	zensical build --strict
+
+preview:
+	zensical serve

docs/ci.md

@@ -263,7 +263,7 @@ architecture. If we click on `Details` for one of the runs, we get taken to wher
 and the output it is generating.
 
 The run is broken down into `steps`, each of which has a name. The one we are interested in is
-`Build and test our package`, which is where we defined our build processs. While the build is running we can read the
+`Build and test our package`, which is where we defined our build process. While the build is running we can read the
 output, or we can view it after the run completes. Regardless, we note that the output is almost identical to that
 which we had when we ran the workflow ourselves. This is no more than we expect in reality, since this is what EESSI
 is supposed to deliver for us.

docs/getting-access.md

@@ -32,7 +32,7 @@ README.eessi  defaults  host_injections  init  versions
 ```
 
 For starting to use EESSI, continue reading about
-[Setting up environment](eessi-usage.md#setting-up-your-environment).
+[Setting up environment](usage.md#setting-up-your-environment).
 
 If you see an error message as shown below, **EESSI is not yet accessible on your
 system**.
@@ -182,6 +182,6 @@ ls /cvmfs/software.eessi.io
 
 ---
 
-To start using EESSI, see [Using EESSI](eessi-usage.md).
+To start using EESSI, see [Using EESSI](usage.md).
 
 [*(back to overview page)*](index.md)

docs/index.md

@@ -12,14 +12,14 @@ EESSI provides a shared, portable, and optimized software stack for scientific c
 
 ## Tutorial Contents
 
-(For those attending the live tutorial at ISC26, there is a [prepared environment](prepared-environment.md) available.)
+For those attending the live tutorial at ISC26, there is a [prepared environment](prepared-environment.md) available.
 
-1. [Getting Access to EESSI](eessi-getting-access.md)
-2. [Introduction to EESSI](eessi-introduction.md)
-3. [Using EESSI](eessi-usage.md)
-4. [EESSI Use Cases](eessi-use-cases.md)
+1. [Introduction to EESSI](introduction.md)
+2. [Getting Access to EESSI](getting-access.md)
+3. [Using EESSI](usage.md)
+4. [EESSI Use Cases](use-cases.md)
 5. [Installing on top of EESSI](installing-on-top.md)
-6. [Using EESSI in CI](eessi-in-ci.md)
+6. [Using EESSI in CI](ci.md)
 7. [Advanced topics](advanced-topics.md)
 
 ## Learning Objectives

docs/installing-on-top.md

@@ -10,7 +10,7 @@
 EESSI is sometimes described as "container without a container runtime". What that means is that it effectively
 provides an alternative operating system to the native one without the need for something to negotiate between the two.
 When we are _consuming_ software from EESSI, there is no real way to see this. It is only when we try to use EESSI as a
-basis for building new sotware that we are exposed to the addional complexity that this can bring.
+basis for building new sotware that we are exposed to the additional complexity that this can bring.
 
 ## Building a software project
 
@@ -380,7 +380,7 @@ There are a few things that can impact the behaviour of the runtime loader:
   store information about the paths to search when looking for libraries. This can be done in such a way that it can
   be overridden by `LD_LIBRARY_PATH` (`RUNPATH` linking), or in a way where `LD_LIBRARY_PATH` has no influence
   (`RPATH` linking).
-* The runtime loader also has default locations it searchs for libraries. These are used as a last resort.
+* The runtime loader also has default locations it searches for libraries. These are used as a last resort.
 
 For a given application or library, we can inspect what the runtime loader will resolve the shared libraries to
 using the command `ldd`. For our failed build, we can do this on the binary `hello_mpi_hdf5`, which was created by our
@@ -407,7 +407,7 @@ we cannot use `LD_LIBRARY_PATH` to help the loader to find libraries (as setting
 host runtime loader, which may unintentionally break applications coming from the host). EESSI therefore must use
 `RPATH`-linking for all of the programs it ships in the software layer.
 
-We can inspect the RPATH information encoded in a libary using a tool called `patchelf` (which is
+We can inspect the RPATH information encoded in a library using a tool called `patchelf` (which is
 shipped in EESSI):
 ``` { .bash .no-copy }
 {EESSI/2025.06} $ patchelf --print-rpath hello_mpi_hdf5
@@ -671,7 +671,7 @@ module load EESSI-extend/2025.06-easybuild
 ### Using `EESSI-extend` to install a package with  EasyBuild
 
 First, we need something that we want to install. For the purposes of this tutorial we are going to use a build
-recipe (or _easyconfig_) for EasyBuild targetting the package we have been working with to date.
+recipe (or _easyconfig_) for EasyBuild targeting the package we have been working with to date.
 
 !!! warning
 

requirements.txt

@@ -0,0 +1 @@
+zensical