What are "stages" and "jobs" in the context of GitLabCI?

stages are, say, general "labels." An internship only begins when the previous stage ends. Within a single stage, however, several distinct jobs may be run in parallel.

Take, for example, the following pipeline :

Ithas3stages,inorder:

Inturn,theyaredividedintothefollowingjobs:

Intheimageitisverycleartherelationofexecutiondependency.Internally,whathappens:

As the cache is only used within the same pipeline , shared by jobs ,% cache , but this will have no practical effect.

Following are significant excerpts from test-mobile that result in this 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 my stages , not the default stages . If nothing is defined, GitLab behaves as if there are stages ( source a>):

stages:
  - build
  - test
  - deploy

This 3-stage pipeline has answered me when doing builds of libraries, but I needed something more now. The idea is to continue with more stages and all the steps of build here, but I'm working calmly.

Then I specify the cache that will be shared with the jobs . I needed to use .gitlab-ci.yml protected with single quotes to prevent YAML from having special interpretation.

  

Note: If you set a cache within the job , it overwrites the cache definition. There will be merge ! That already gave me a headache.

After these two settings, I go after setting up my jobs . Each job needs to indicate its stage and have a running script. The script is the same command line, no secrets. You can abuse bash if your build machine is Linux =)

I made a point of putting one job dependent on the other to run, as this gives me a greater freedom to by execution condition of some job and avoid that jobs can run. The idea is that when I finish, there is an automatic job for the portal and the mobile that is executed just by uploading a tag , then having job manual to get the executable under test.

In the case of the test test, I had him archive files:

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

In this case, I'm archiving only when build fails ( '*/target' ). Since they are bug-checking results in automated testing, I do not care if they spend too much time in the air, so I put expiration time of 1 week (% with%). The files to be archived are either within when: on_failure , or else combine with expire_in: 1 week glob.