Gitlab

CELS Systems provides an on-premise git repository running Gitlab at git.cels.anl.gov. This service is accessible both onsite and remotely without need for VPN.

Getting access

A GCE account is required to access git.cels.anl.gov.  If you do not have an account, please see GCE Accounts for more information on how to get one. Non-Argonne collaborators on your projects can also obtain accounts through this method. You do not need to request access to git.cels.anl.gov, your GCE account entitles you to that. However your account will not exist on the server until you login.

Login using your GCE credentials to access the web interface, and be sure to add your SSH Key to your profile.  Full instructions on how to interact with Gitlab can be found at Gitlab’s site, however we will provide instructions specific to our installation here.

If there are features you require out of gitlab that we do not have enabled, please let us know.

Security

As noted above, the service is available globally.  You may choose to make your repository as publicly accessible as you’d like for read-only access, you can only allow logged-in users to see it, or you can make it completely private except to specific people and groups.

CI/CD

We support Continuous Integration/Continuous Delivery workflows, tied to GCE compute resources.  Gitlab’s CI/CD documentation can be found at https://docs.gitlab.com/ee/ci/README.html. In the context of these CI/CD docs, when we refer to “public”, we mean within GCE.  The executors run on GCE compute nodes which are only accessible to other GCE accountholders.

Specific to our installation, there are 3 shared runners with the following settings:

• uses ssh as executor
• configured to use the GCE compute nodes: compute-02, compute-04, compute-06
• have the following tags: public, shared_ssh

NOTE: Due to the way the ssh shared runners are configured it is possible that a project’s CI/CD testing could be viewable by another project using the shared runners. The shared runners are only suitable for public projects. If your project has other needs please contact CELS Systems so we can work to find something suitable for your needs.

GitLab CI/CD is configured by a file called .gitlab-ci.yml placed at the repository’s root. It is strongly recommended you review Gitlabs documentation as there is a wide range of options

Basic examples:

In the following examples use a repo with a few hello worlds written in a different languages.

fritz@homes-01:~/projects/ci_testing$ ls -la
total 144
drwxr-xr-x 3 fritz cels 9 Nov 24 13:03 .
drwxr-xr-x 3 fritz cels 3 Oct 7 18:00 ..
drwxr-xr-x 8 fritz cels 14 Nov 24 13:03 .git
-rw-r--r-- 1 fritz cels 1076 Nov 24 13:03 .gitlab-ci.yml
-rw-r--r-- 1 fritz cels 95 Nov 23 16:53 hello_world.c
-rw-r--r-- 1 fritz cels 101 Nov 23 16:53 hello_world.c++
-rw-r--r-- 1 fritz cels 76 Nov 23 16:53 hello_world.f90
-rw-r--r-- 1 fritz cels 76 Nov 23 16:53 hello_world.f95
-rw-r--r-- 1 fritz cels 14 Oct 7 17:53 README.md
fritz@homes-01:~/projects/ci_testing$ 

example 1:
In the first example we build our hello_world.c with gcc, and make sure it runs. The pipeline has a single stage called build, in which we build and run the hello world.  The .gitlab-ci.yml may look something like the following.

default:
 tags:
  - public
  - shared_ssh

build:
 stage: build
 script:
 - gcc hello_world.c -o gcc_hello.out
 - ./gcc_hello.out

NOTE: the tags are given, as those tags are required to run on the public shared_ssh executors.

example 2:
In this example we are going to build the same hello_world.c with gcc, and make sure it runs, but this time we want to separate it into build and test stages of the pipeline.
In this case, the .gitlab-ci.yml may look something like the following.

default:
 tags:
 - public
 - shared_ssh

build:
 stage: build
 artifacts:
  untracked: true
 script:
 - gcc hello_world.c -o gcc_hello.out

test:
 stage: test
 dependencies:
 - build
 script:
 - ./gcc_hello.out

NOTE: In this example we use artifacts to store the untracked files during the build stage. We have also noted that test has a dependency on the build stage.  By default the gitlab runner will do a fetch between stages of the pipeline causing the untracked files to be lost between stages. By using the artifacts we are able to save the work from our build stage for use in the following test stage.

example 3:
In this example our project has decided that we should build and test our hello_world.c with both gcc and Intel’s icc. For this, the .gitlab-ci.yml may look something like the following.

default:
 tags:
 - public
 - shared_ssh

build_gcc:
 stage: build
 artifacts:
  untracked: true
 script:
 - gcc hello_world.c -o gcc_hello.out

build_intel:
 stage: build
 artifacts:
  untracked: true
 script:
 - module load intel/20.2
 - icc hello_world.c -o intel_hello.out

test_gcc:
 stage: test
 dependencies:
 - build_gcc 
 script:
 - ./gcc_hello.out

test_icc:
 stage: test
 dependencies:
 - build_intel
 script:
 - ./intel_hello.out

NOTE: In this example we have 2 build, and 2 test stages.  building the same execrable with both gcc, and icc.