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 would be to use deploy keys and put the private key in the https://docs.gitlab.com/ee/ci/variables/index.html#add-a-cicd-variable-to-a-project.

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