GitLab CI (Continuous Integration) is a feature of GitLab where you can run and test software in a repository on the GitLab server every time you push a new commit. The idea is that the instructions for testing the software in your repository are contained as a command line script in a special file. Whenever you push commits to GitLab, the GitLab server runs these testing commands and gives you feedback on whether your software is working.
CI stands for Continuous Integration. It’s a software engineering methodology that encourages regular testing of a whole software product. This might involve a complex build process in a big project and would contrast with testing specific modules (e.g., unit testing). In our case, the important bit is the practice of running automated tests after each commit.
Why is GitLab CI important in courses at ANU#
Some computing courses at ANU use GitLab CI to help test code you have written in labs or assignments. The outcomes of these tests can be useful as feedback to you (as a student) to know whether you have completed parts of an assignment specification. Your teachres might use CI tests to verify you’ve completed a lab or assignment. Some CI jobs actually create an artefact (a file) that might be used in marking an assignment (e.g., a PDF file showing which tests your code has passed).
This varies by course, but in general it’s important to understand the feedback that GitLab CI is providing to you and how to interpret it. This page is really focussed on interpretation to help you make sense of GitLab CI in the context of your coursework and not so much on creating your own CI jobs.
The kinds of things that CI can check#
GitLab CI can do a lot of different things (if you can write a shell script to do it, CI can do it).
GitLab CI is often used to:
-
check you that required assignment files are present and “filled in” in some way
-
check that the wordcount of a file is within the limit
-
check that your code “compiles”
-
deploy your completed project to a website (so you can test it out and share with others)
-
run tests of different features in your code
-
create a PDF from text files in your for viewing and marking
Different courses use GitLab CI in different ways so you would have to check individual assignment specifications to see if and how it is used.
The life cycle of a CI job#
How does the .gitlab-ci.yml file work?#
Making sense of the CI status#
Reading job logs#
Downloading artefacts#
What are jobs?#
Frequently Asked Questions#
What’s continuous integration?#
Continuous Integration (CI) is just a fancy name for a bunch of commands which
are executed on the GitLab server every time you successfully push a new commit
to your repository. This can be used to do all sorts of things, for example to
check that you haven’t forgotten to commit a file (e.g. references.md) These
commands are called “CI jobs”.
Why am I getting “Pipeline #xxxx has failed…” emails from GitLab?#
This means that:
- you are taking a course that uses GitLab CI
- you have committed code to an assignment or lab repository
- a GitLab CI job has run but not been 100% successful (it may have been partially successful)
It doesn’t necessary mean you have done anything wrong, but you should check the job trace to see what is happening and check your assignment/lab specification to see what you should expect.
This isn’t a guarantee of the “correctness” of your submission (it doesn’t actually run your code), it’s a just a checklist of the very basic things your code must do (like compile successfully).
So if all the CI tests pass, do I get 100% for the assignment?#
No. It just checks the “bare minimum”, that your assignment is valid and the most important components are in place.
Should I be worried if my submission fails the CI checks?#
Not initially. What you need to do is have a look at what has failed and make sure that you’re working towards fixing them up. As the submission deadline approaches and you finish off your assignment you should see fewer and fewer failures.
How long does my CI job take to run?#
Most CI jobs take less than one minute to run. However, if there may be a lot of students pushing code to gitlab, and we’ve only got a limited number of servers to run the CI jobs on, so it’s quite likely that your job won’t start straight away if the servers are already busy.
Your CI job goes into a queue and will run as soon as possible. So if a lot of people are pushing (e.g. if it’s close to the deadline) then you might have to be a bit patient.
If the CI job takes ages to run, does that mean my code hasn’t been accepted before the deadline?#
No. The CI checks are just there to provide helpful feedback to you—they have no impact on whether your code is submitted (or the time of submission). The submission time is based only on the timestamp when GitLab receives your push.
Can I see whether my submission passes the CI checks through the GitLab web interface?#
Yes. Go to the web interface for your repo, and click on “CI / CD” in the sidebar. You’ll see a view which gives you info about the last CI run (which should have happened last time you pushed).
I’m sick of getting these CI emails, can I disable them?#
Yes—if you want to disable this email notification, go to your account setting in GitLab (click on your profile picture, then select Notifications). Change the notification level of your assignment repo to “Custom”, then in the pop-up window de-select “Failed pipeline”.
Can I modify the .gitlab-ci.yml file?#
Usually this isn’t a good idea unless your course convenor specifically allows you to do so