Continuous Integration (CI)

The basic idea of CI is that whenever you push a commit, tests start running automatically on some server.
If the tests pass, you have a bit more confidence that the code that you pushed doesn't break other things in the codebase.
If they fail, then the CI has generated some work for you

In our case, a CI pipeline has been set up at https://git.cs.lth.se/robotlab/heron/heron-ci/
For now, the only thing it does is spin up a ROS noetic docker image to follow the instructions in the readme of https://git.cs.lth.se/robotlab/heron/heron_workspace_setup/-/tree/noetic
If it builds, the pipeline succeeds. Important to note is that it checks out some repositories at `noetic`, not `master`.

Just like a normal git user, the CI pipeline also needs to prove it has the authority to clone a repository.
As we know, there are 2 main ways to do that: over HTTPS (user/password), or over SSH (private/public key).
In our case, the rosinstall files are defined using SSH (git@someurl), so that is what's used in the CI as well.

Best practice is to use deploy keys and put the private key in the CI variables. This is what we are doing.

You can use the environment variable $CI_JOB_TOKEN for free. It's included. You don't have to do anything.

some_early_stage:
  script:
    - git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.instance/group/project.git

We want the main pipeline to be triggered if a commit happens in ANY of the repositories that the pipeline depends on.
This can be achieved by putting the following .gitlab-ci.yml in each of those repos, in the right branch of course (i.e. the branch the pipeline uses).

trigger-main:
  trigger: 
    project: robotlab/heron/heron-ci
    branch: main
    strategy: depend

I learned that here: https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html