easybuilders · ocaisa · Jun 19, 2026 · Jun 19, 2026 · Jun 19, 2026 · Jun 19, 2026
diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
@@ -8,12 +8,12 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: checkout
-      uses: actions/checkout@v3
+      uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # 7.0.0
       with:
           fetch-depth: 0
 
     - name: set up Python
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
       with:
         python-version: 3.8
 

diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml
@@ -6,15 +6,15 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - name: checkout
-      uses: actions/checkout@v3
+      uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # 7.0.0
 
     - name: set up Python
-      uses: actions/setup-python@v4
+      uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
       with:
         python-version: 3.8
 
     - name: Codespell action
-      uses: codespell-project/actions-codespell@master
+      uses: codespell-project/actions-codespell@8f01853be192eb0f849a5c7d721450e7a467c579 # 2.2
       with:
         check_filenames: true
         # Ignore a listed standard mistake in CodeSpell by listing it in the same case that it appears in that list
@@ -23,7 +23,7 @@ jobs:
         uri_ignore_words_list: UES,ues
 
     #- name: Markdown Linting Action
-    #  uses: avto-dev/markdown-lint@v1.2.0
+    #  uses: avto-dev/markdown-lint@04d43ee9191307b50935a753da3b775ab695eceb # v1.5.0
     #  with:
         # rules: '/lint/rules/changelog.js'
         # config: '/lint/config/changelog.yml'

diff --git a/docs/2020-06-isc20/hmns.md b/docs/2020-06-isc20/hmns.md
@@ -54,7 +54,7 @@ If you run "`module avail`" with the example module hierarchy, you will only see
 
 Some modules in the top level of the hierarchy act as a "gateway" to modules in the
 next level below.
-To make additional modules available for loading one of these gateway modules has to be loaded. In our exampe, loading the `GCC/9.3.0` module results in two additional modules coming into view from the compiler level, as indicated by the arrows: the modules for `OpenMPI` and `MPICH`. These corresponds to installations of `OpenMPI`
+To make additional modules available for loading one of these gateway modules has to be loaded. In our example, loading the `GCC/9.3.0` module results in two additional modules coming into view from the compiler level, as indicated by the arrows: the modules for `OpenMPI` and `MPICH`. These corresponds to installations of `OpenMPI`
 and `MPICH` that were built using `GCC/9.3.0` as a toolchain.
 
 Similarly, the `OpenMPI/4.0.3` module serves as a gateway to the three modules in the MPI level. Only by loading the `OpenMPI` module will these additional three modules become

diff --git a/docs/2021-isc21/basic_usage.md b/docs/2021-isc21/basic_usage.md
@@ -105,7 +105,7 @@ file extension *does* matter when easyconfig files are being picked up in subdir
 File names for easyconfigs being mostly irrelevant is only correct with respect to the arguments passed to
 the `eb` command however. As we will learn soon, the name of easyconfig files *does* matter (a lot)
 when EasyBuild needs to locate easyconfigs that can be used to resolve a specified dependency
-(see [here](#enabling-dependency-resolution)).
+(see [here](installing_software.md#enabling-dependency-resolution)).
 
 This explains why easyconfig files usually adher to a very specific naming scheme,
 corresponding to `<name>-<version>-<toolchain><versionsuffix>.eb`, where:

diff --git a/docs/2021-isc21/contributing.md b/docs/2021-isc21/contributing.md
@@ -350,7 +350,7 @@ Opened pull request: https://github.com/ebtutorial/easybuild-easyconfigs/pull/
 ```
 
 Take a moment to grasp what we did here: we ran **a single `eb` command** which
-took care of the **[whole contribution procedure](#contribution-procedure)** for us, including:
+took care of the **[whole contribution procedure](#manual-contribution-procedure)** for us, including:
 
 * Cloning the `easybuilders/easybuild-easyconfigs` repository and checking out the `develop` branch (in a temporary
   directory);

diff --git a/docs/2021-isc21/module_naming_schemes.md b/docs/2021-isc21/module_naming_schemes.md
@@ -53,7 +53,7 @@ If you run "`module avail`" with the example module hierarchy, you will only see
 
 Some modules in the top level of the hierarchy act as a "gateway" to modules in the
 next level below.
-To make additional modules available for loading one of these gateway modules has to be loaded. In our exampe, loading the `GCC/9.3.0` module results in two additional modules coming into view from the compiler level, as indicated by the arrows: the modules for `OpenMPI` and `MPICH`. These correspond to installations of `OpenMPI`
+To make additional modules available for loading one of these gateway modules has to be loaded. In our example, loading the `GCC/9.3.0` module results in two additional modules coming into view from the compiler level, as indicated by the arrows: the modules for `OpenMPI` and `MPICH`. These correspond to installations of `OpenMPI`
 and `MPICH` that were built using `GCC/9.3.0` as a (compiler-only) toolchain.
 
 Similarly, the `OpenMPI/4.0.3` module serves as a gateway to the three modules in the MPI level. Only by loading the `OpenMPI` module will these additional three modules become

diff --git a/docs/2021-lust/github_integration.md b/docs/2021-lust/github_integration.md
@@ -350,7 +350,7 @@ Opened pull request: https://github.com/ebtutorial/easybuild-easyconfigs/pull/
 ```
 
 Take a moment to grasp what we did here: we ran **a single `eb` command** which
-took care of the **[whole contribution procedure](#contribution-procedure)** for us, including:
+took care of the **[whole contribution procedure](#manual-contribution-procedure)** for us, including:
 
 * Cloning the `easybuilders/easybuild-easyconfigs` repository and checking out the `develop` branch (in a temporary
   directory);

diff --git a/docs/2021-lust/module_naming_schemes.md b/docs/2021-lust/module_naming_schemes.md
@@ -53,7 +53,7 @@ If you run "`module avail`" with the example module hierarchy, you will only see
 
 Some modules in the top level of the hierarchy act as a "gateway" to modules in the
 next level below.
-To make additional modules available for loading one of these gateway modules has to be loaded. In our exampe, loading the `GCC/9.3.0` module results in two additional modules coming into view from the compiler level, as indicated by the arrows: the modules for `OpenMPI` and `MPICH`. These correspond to installations of `OpenMPI`
+To make additional modules available for loading one of these gateway modules has to be loaded. In our example, loading the `GCC/9.3.0` module results in two additional modules coming into view from the compiler level, as indicated by the arrows: the modules for `OpenMPI` and `MPICH`. These correspond to installations of `OpenMPI`
 and `MPICH` that were built using `GCC/9.3.0` as a (compiler-only) toolchain.
 
 Similarly, the `OpenMPI/4.0.3` module serves as a gateway to the three modules in the MPI level. Only by loading the `OpenMPI` module will these additional three modules become
@@ -268,7 +268,7 @@ $ eb SciPy-bundle-2020.11-foss-2020b-Python-2.7.18.eb -D
 
 !!! Warning
     **This exercise will only work if you have write access to the software installation prefix**,
-    because EasyBuild will try to copy the installation log file to each installlation directory.
+    because EasyBuild will try to copy the installation log file to each installation directory.
 
 Now that we know more about hierarchical module naming schemes,
 let us see how EasyBuild can help us with generating a hierarchical module tree.
@@ -606,4 +606,4 @@ module unuse $MODULEPATH
 
 !!! Warning
     **This exercise will only work if you have write access to the software installation prefix**,
-    because EasyBuild will try to copy the installation log file to each installlation directory.
+    because EasyBuild will try to copy the installation log file to each installation directory.
diff --git a/docs/2022-isc22/integration_lumi.md b/docs/2022-isc22/integration_lumi.md
@@ -381,7 +381,7 @@ Cray PE and hence each version of the LUMI software stack.
 EasyBuild comes with a lot of [software-specific easyblocks](https://docs.easybuild.io/en/latest/eb_list_easyblocks.html).
 These have only been tested with the common toolchains
 in the automated EasyBuild test procedures. As a result, many of those easyblocks will fail with the Cray toolchains
-(and with many other custom toolchains). A common problem is that they don't recongnise the compilers as they test 
+(and with many other custom toolchains). A common problem is that they don't recognise the compilers as they test 
 for the presence of certain modules and hence simply stop with an error message that the compiler is not 
 recognised, but there may also be more subtle problems, like explicitly checking for the name of a dependency rather
 than for the presence of the corresponding `EBROOT` and `EBVERSION` environment variables through the EasyBuild API.

diff --git a/docs/2023-eb-eessi-uk-workshop/easybuild-configuration.md b/docs/2023-eb-eessi-uk-workshop/easybuild-configuration.md
@@ -29,7 +29,7 @@ and cover only the most prominent and important ones.
     and omit the leading dashes (`--`) for the sake of clarity.
 
 Keep in mind that *every* configuration setting can be defined in 3 different ways,
-see [below](#consistency-across-configuration-levels) for more details.
+see [below](#configuration-levels) for more details.
 
 ---
 

diff --git a/docs/2023-eb-eessi-uk-workshop/easybuild-installation.md b/docs/2023-eb-eessi-uk-workshop/easybuild-installation.md
@@ -15,7 +15,7 @@ for the remainder of this tutorial.
         * An environment modules tool (Lmod is recommended)
     * *Installation methods*:
         * [``pip install easybuild``](#method-1-using-pip)
-        * [installing EasyBuild with EasyBuild](#method-2-bootstrapping-easybuild)
+        * [installing EasyBuild with EasyBuild](#step-2-using-easybuild-to-install-easybuild)
         * [development setup](#method-3-development-setup)
     * Verify EasyBuild installation by running `eb` commands.
 

diff --git a/docs/2023-eb-eessi-uk-workshop/eessi-getting-access.md b/docs/2023-eb-eessi-uk-workshop/eessi-getting-access.md
@@ -6,7 +6,7 @@ of the EESSI repository.
 ## Is EESSI accessible?
 
 EESSI can be accessed via [a native (CernVM-FS) installation](#native-installation),
-or via [a container that includes CernVM-FS](#eessi-container).
+or via [a container that includes CernVM-FS](#eessi-client-container).
 
 Before you look into these options, check if EESSI is already accessible on your system.
 
@@ -26,7 +26,7 @@ host_injections  latest  versions
 ```
 
 For starting to use EESSI, continue reading about
-[Setting up environment](eessi-usage.md#setting-up-environment).
+[Setting up your environment](eessi-usage.md#setting-up-your-environment).
 
 If you see an error message as shown below, **EESSI is not yet accessible on your
 system**.
@@ -36,7 +36,7 @@ ls: /cvmfs/pilot.eessi-hpc.org: No such file or directory
 No worries, you don't need to be a :mage: to get access to EESSI.
 
 Continue reading about the [Native installation](#native-installation) of EESSI,
-or access via the [EESSI container](#eessi-container).
+or access via the [EESSI client container](#eessi-client-container).
 
 ## Native installation
 

diff --git a/mkdocs.yml b/mkdocs.yml
@@ -152,8 +152,8 @@ markdown_extensions:
       permalink: true
   # emojis
   - pymdownx.emoji:
-      emoji_index: !!python/name:materialx.emoji.twemoji
-      emoji_generator: !!python/name:materialx.emoji.to_svg
+      emoji_index: !!python/name:material.extensions.emoji.twemoji
+      emoji_generator: !!python/name:material.extensions.emoji.to_svg
 extra:
   # add links in bottom right
   social: