When using BEAR GitLab, its possible to use continuous integration to undertake automated tasks when code is committed to your project. This is often used to automate running of code validation tool, running test cases or even building packages for deployment. Within GitLab, this feature is provided by GitLab runners. Whilst researchers are able to setup their own runners outside of the BEAR environment, we provide a number of shared runners which are available for all BEAR GitLab projects to use. As they are provided as part of the service, we ensure that we have monitoring of them to ensure their availability.

Using the shared runners

Initial project config

To use the BEAR GitLab shared runners, they first need to be enabled within the project in GitLab. From the GitLab web interface, select the "Settings" item from the left hand menu and chose "CI/CD":

 

Scroll down until you find the "Shared Runners" section and click the "Enable shared Runners" button:

 

You've now enabled the shared runners for your repository. You'll need to do this for each git repository you want to use CI for.

To actually do something as part of CI, you now need to define the config.

Enabling CI tests

Within GitLab, CI is enabled by creating a file called ".gitlab-ci.yml" at the root of the repository. It is important to note that to use the shared runners, you need to include the tag telling GitLab which runners you wish to use, this is done per task within the CI config file and should be set to "bear-gitlab-runners". An example file is given below:

---
image: python:3.6


stages:
  - lint
  - test

before_script:
  - python -V
  - apt-get update -y

flake8:
  stage: lint
  tags:
    - bear-gitlab-runners
  script:
    - pip install flake8
    - flake8 --version
    - flake8 -v

test:
  stage: test
  tags:
    - bear-gitlab-runners
  script:
    - pip install -r requirements.txt
    - python get_globus_data.py --help

By default, the run will start by doing a "git fetch" command to pull either master or the relevant branch. This will take place whenever a code is pushed to the repo. In the example above, we perform a two-stage pipeline with both stages using a Python 3.6 Docker image. The first stage is named "flake8" - and there are three steps, the first is to install flake8, then dump the version before running flake8 in verbose mode. Flake8 incidentally is a tool used for checking the style and basic syntax checking of Python code. The second stage is named "test" and in this case we attempt to install the required Python modules before doing a very simple test on the starting the Python code.

Accessing the Test Reports

To access a test report from a CI pipeline, start by viewing the Pipelines page in the CI/CD menu:This will show you the pipelines run in the repository, with the most recent one listed at the top. Selecting the pipeline will take you to a page with details about the stages of the pipeline.Finally, you can select an individual stage to see the report of that stage of the pipeline, which will help you to debug any failures.

More Information

For more help and assistance, please check the GitLab runners documentation.