What are "Stages" and "Jobs" in the context of Gitlabci?

Question

Seeing here the option of put the IC in Gitlab (https://docs.gitlab.com/ee/ci/README.html). I was in doubt about the nomenclature they use.

They say it all goes in one pipeline (https://docs.gitlab.com/ee/ci/pipelines.html), and that this is the "assembly line" of my software. This pipeline, in turn, it is divided into Stages and Jobs.

• What are Stages?
• What are Jobs?

Related:

• What is Travis CI?
• What is CI/CD? Benefits and Risks

Answer 1

Stages are, shall we say, general "labels". A stage only begins when the previous stage ends. Within a single stage, however, several Jobs can be executed in parallel.

Take, for example, the following pipeline:

It has 3 stages, in order:

1. build-test-nucleo
2. build-apps
3. test-apps

In turn, they are divided into the following Jobs:

1. build-test-nucleo
   • build-nucleo
2. build-apps
   • build-mobile
   • build-portal
3. test-apps
   • test-mobile

In the image it is clear the relation of dependency of execution. Internally, what happens:

1. one Runner raises a container to accomplish the job build-nucleo; when you’re done guard a cache (if there is any)
2. when the previous stage ends, the following will occur in parallel:
   • one Runner raises another container to accomplish the job build-mobile; will also guard cache if there is
   • another Runner raises one more container to accomplish the job build-portal; will also guard cache if there is
3. when the two of you Jobs of the previous stage to end, the job test-mobile will be called.

Like the cache is only used within it pipeline, shared by Jobs, the test-mobile may even keep a cache, but this will have no practical effect.

Next, significant excerpts from .gitlab-ci.yml resulting in that pipeline:

stages:
  - build-test-nucleo
  - build-apps
  - test-apps

cache:
  - .m2
  - '*/target'

build-test-nucleo:
  stage: build-test-nucleo
  script:
    - cd nucleo
    - mvn compile test
    - cd ..

build-mobile:
  stage: build-apps
  script:
    - cd mobile
    - mvn compile
    - cd ..
  dependencies:
    - build-nucleo

build-portal:
  stage: build-apps
  script:
    - cd portal
    - mvn compile
    - cd ..
  dependencies:
    - build-nucleo

test-mobile:
  stage: test-apps
  script:
    - cd mobile
    - mvn test
    - cd ..
  dependencies:
    - build-mobile
  artifacts:
    paths:
      - mobile/*.dump*
      - mobile/target/
    when: on_failure
    expire_in: 1 week

Explaining:

First, I wanted to use mine Stages, not them Stages default. If nothing is set, Gitlab behaves as if these Stages (source):

stages:
  - build
  - test
  - deploy

That one pipeline of 3 stages already attended me to do builds of libraries, but I needed something more now. The idea is to continue with more stages and by all the steps of build here, but I’m working slowly.

Then I specify the cache that will be shared with the Jobs. I had to use '*/target' protected by simple quotation marks to prevent YAML from being interpreted in a special way.

Note: if you set one cache within the job, it will override the definition of cache. There won’t be merge! It’s given me a headache.

After these two settings, I’m going after to assemble my Jobs. Each job need to indicate your Stage and have an execution script. The script is the same command line, no secrets. You can abuse the bash if your build machine is Linux =)

I made sure to put that one job depends on the other to be executed, because it gives me a greater freedom to by conditional execution of some job and prevent Jobs artists are executed. The idea is that when I’m done, there’s a job automatic packaging for the portal and mobile that runs only when climbing a tag, to then have the job manual to put the executable to test.

In the case of job test, I had him file files:

artifacts:
  paths:
    - mobile/*.dump*
    - mobile/target/
  when: on_failure
  expire_in: 1 week

In case, I’m only filing when there are gaps in the build (when: on_failure). Since these are results for bug inspection in automated testing, I don’t care how long they stay in the air, so I put an expiration time of 1 week (expire_in: 1 week). Files to be archived or are inside mobile/target, or they match the glob mobile/*.dump*.