Skip to content
Snippets Groups Projects
Commit 9d9ad3e1 authored by Lukas Werner's avatar Lukas Werner
Browse files

Improved documentation

parent 1b864a09
No related merge requests found
...@@ -7,7 +7,7 @@ ...@@ -7,7 +7,7 @@
### Setting up authentification ### Setting up authentification
To ensure, that a given repository is entitled to run CI jobs as a given user, a authentification strategy using SSH keys is employed. To ensure that a given repository is entitled to run CI jobs as a given user an authentification strategy using SSH keys is employed.
Most CI configuration happens in the `.gitlab-ci.yml` file. Most CI configuration happens in the `.gitlab-ci.yml` file.
However, to make the private SSH key available in the pipeline without exposing it in `.gitlab-ci.yml` a "secret" CI variable needs to be set. However, to make the private SSH key available in the pipeline without exposing it in `.gitlab-ci.yml` a "secret" CI variable needs to be set.
...@@ -41,6 +41,7 @@ benchmark-broadep2: ...@@ -41,6 +41,7 @@ benchmark-broadep2:
``` ```
This configuration already suffices to have the CI jobs running on the node `phinally`. This configuration already suffices to have the CI jobs running on the node `phinally`.
With "phinally" being the default node and time limit by default at 120, even having no configuration at all would work just fine.
To pick a node to run your job on, set `SLURM_NODELIST` to the nodes hostname. To pick a node to run your job on, set `SLURM_NODELIST` to the nodes hostname.
`SLURM_NODELIST` can only hold a single entry, as usage of multiple nodes at once is not available on the test cluster. `SLURM_NODELIST` can only hold a single entry, as usage of multiple nodes at once is not available on the test cluster.
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment