====== Continuous Integration (CI) ======

===== Introduction =====

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`.

​

​

===== Authorization to clone git repos =====

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. \\

​

=== SSH ===

Best practice is to use [[https://docs.gitlab.com/ee/user/project/deploy_keys/index.html|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|CI variables]]. This is what we are doing.

​

=== HTTPS ===

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

<code yaml>

some_early_stage:

  script:

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

</code>

​

==== Propagating CI triggers ====