Continuous integration: the server and its runners
How a continuous integration server such as GitLab CI or GitHub Actions works: triggers, runners, cache and artifacts, masked secrets, reproducible builds and protected branches.
- 27 cards
- 4 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Concepts
- Questions
- Sort and link
- Scenarios
A few cards from the deck
Continuous integration: what is it?
Show the answer
The practice of merging work into the shared branch often, each merge automatically triggering a build and tests.
The more often you merge, the smaller and easier to find the conflicts and regressions are: the server tells you within minutes whether the change breaks anything.
With this rule, a developer pushes a commit to the
fix-loginbranch without opening a merge request. What happens?
```yaml
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == "main"`- No pipeline starts
- A pipeline starts, as for any push
- A pipeline starts, but without the test jobs
- The server rejects the push
Show the answer
No pipeline starts
The two rules are read in order and the first one that is true decides. A push to
fix-loginis neither a merge request event nor onmain: no rule matches, so there is no pipeline.The runner hands each job to an …, which decides where it runs: most often a container created for the occasion then destroyed, which keeps two jobs from polluting each other.
Show the answer
The runner hands each job to an executor, which decides where it runs: most often a container created for the occasion then destroyed, which keeps two jobs from polluting each other.
A job that starts from a clean environment shows what is really missing: no file left behind on a workstation makes it pass by mistake. The shell executor, by contrast, runs the job directly on the runner's machine, without that isolation.
Pipeline trigger: what is it?
Show the answer
The event that starts a run: a push of commits, a merge request, a tag, a schedule or a manual launch.
A pipeline does not start by itself: a rule says for which events and branches it runs. Without a suitable rule, a merge request may never be tested.
The tests pass on the developer's workstation and fail on the server, with a syntax error in a dependency. Which fix addresses the cause?
- Rerun the job several times until it finally passes
- Pin the job's image and lock the dependency versions
- Turn the tests off on the server and run them only locally
- Empty the server's cache before every job to start from scratch
Show the answer
Pin the job's image and lock the dependency versions
The workstation and the server do not have the same versions of the language or dependencies. A pinned image and a lock file give the same environment everywhere. Rerunning or cutting the tests hides the problem.