Deploying a Service

In a Conda Environment

Conda environment definitions are located in the conda group.

These definitions include two files:

  • A meta.yml file containing general information about the environment,
  • An env.yml definition file.

Upon a push, the Conda environment will be automatically created from the env.yml file with a name in the format [project_name]-[branch_name]-rpbs and placed in /shared/software/conda/envs/.

A module file will also be created and placed in /shared/software/modulefiles/.

You can then load the module by typing, for example:

module load alphafold/2.1.1-rpbs

Note: The -rpbs suffix is automatically added to the branch/version name to avoid confusion with environments deployed via NNCR.

You can also manually trigger a pipeline to deploy the environment. To do this:

  1. Go to CI/CD > Pipelines,
  2. Click on Run pipeline,
  3. In the Run for branch name or tag menu, select the branch/version,
  4. Click on Run pipeline.

In a Container (Docker/Singularity)

Container definitions for Docker/Singularity are located in the docker group.

These definitions include a Dockerfile and all necessary files to build the container.

Upon a push, the container will be automatically created from the Dockerfile with a name in the format [project_name]-[branch_name]-rpbs.sif and placed in /shared/software/singularity/images/.

If the branch/version name does not contain the -dev suffix, the directories defined by the PATH variable (e.g., /usr/local/bin) will be scanned for executable files. A wrapper file will be created for each executable and placed in /shared/software/singularity/wrappers/.

A module file will also be created and placed in /shared/software/modulefiles/.

You can then load the module by typing, for example:

module load pepfold-core/1.0-rpbs

Note: The -rpbs suffix is automatically added to the branch/version name to avoid confusion with environments deployed via NNCR.

You can also manually trigger a pipeline to deploy the container. To do this:

  1. Go to CI/CD > Pipelines,
  2. Click on Run pipeline,
  3. In the Run for branch name or tag menu, select the branch/version,
  4. Click on Run pipeline.

Including Git Submodules

Git submodules allow you to manage a Git repository as a subdirectory of another Git repository. This lets you clone repositories into the project while keeping the commits of the submodule isolated.

To add a submodule:

git submodule add git@172.27.7.118:src/PyPDB.git src/PyPDB

or:

git submodule add ../src/PyPDB.git src/PyPDB

Warning: The repository included as a submodule must be public to ensure accessibility by the GitLab integration pipeline.

Don’t forget to track the newly created .gitmodules file:

git add .gitmodules

To fetch the latest version of the submodule:

git submodule update --remote

Remember to commit the main Git repository again so that Git updates the pointers to the submodules.

Note: The GitLab integration pipeline always fetches the latest available version of submodules during container builds.