Speaking of which, I have been using Gitlab for more than half a year. I have been running pipelines every day, but I haven’t studied this file called Gitlab-ci.yML. This time, I took the opportunity to release the process update and get a good introduction. The main contents are as follows:

  • stages
  • cache
  • only
  • when
  • Before_script, script, after_script
  • artifacts
  • hidden_job && extends
  • reserved keywords – include
  • tags

stages:

“Stages” is used to define a pipeline. A pipeline, like an assembly line, is made up of a series of stages. Take a famous story as an example, putting the elephant into the refrigerator is a pipeline, so opening the refrigerator door, putting the elephant into the refrigerator, and closing the refrigerator 🚪 is 3 stages. If lint, test, build are published, the four stages form a pipeline that looks like this:

stages
  - lint
  - test
  - build
  - publish
Copy the code

Then you can see the following diagram under gitlab pipeline:

Although we have defined a pipeline and four stage names above, it is not clear what each stage does. What stages do is defined by job. Now let’s learn how to define a job.

job

For example, we need to run NPM run lint to check for lint errors. This job can be written as:

job-lint:
  stage: lint
  script: npm run lint
Copy the code

Where job-lint is the task name, script is the command to be executed at the terminal, and stage indicates which stage (a node of the pipeline) the job belongs to. One thing to note about job names is that you can’t use reserved characters. For example, you can’t call a job “stages” or “image” just as you can’t call a variable “if”. The documentation can be found here.

A stage can have multiple jobs, and a job can perform multiple scripts. For example, if you want to pack it for Windows, MAC, or Linux, you can do this:

job-build-mac:
  stage: build
job-build-win;
  stage: build
job-build-linux:
  stage: build
Copy the code

Sometimes we want tasks to be executed under certain scenarios, such as building while tagging, using only/except instead.

variables

Environment variables such as development,production, a URL, or a token that does not want to be displayed on the console can be used as environment variables. There are usually three ways to set an environment variable: In project Settings, in a YML file, or through the API.

The entry for configuring environment variables through the project Settings screen is as follows:



Under variables, you can configure variable names and values, usually variables that need to be kept secret

Of course we can also set in YML:

variables:
  TEST: "HELLO WORLD"
Copy the code

You can then reference it in your script:

  script:
    - echo $TEST 
Copy the code

only/except

For the above scenario, we could write job-build like this:

job-build:
  stage: build
  script: npm run build
  only:
    - tags
Copy the code

Thus, the job above is only triggered when we push the tags. If we want a job to be fired only when a certain type of branch is committed, we can do this:

job-bugfix-build:
  stage: build
  script: npm run build
  only:
    - /^bugfix-.+$/
Copy the code

The example above only triggers job-bugfix-build if the branch prefixed with bugfix produces a commit.

However, this is not enough to make the task run, since CI runs inside the docker. Before executing Run Lint, we need to put the Node environment together, which requires the image to retain the word:

image: 12.18 the node:
Copy the code

After adding the image, before the task starts, we also need to install dependencies, which we do using before_script:

# Use node mirroring
image: 12.18 the node:

# install dependencies
before_script:
 - npm install
Copy the code

We can use Expect when we want to not perform a task in certain scenarios, such as not lint hotfixes:

job-lint-except-hotfix:
  script: 
    - npm run lint
  except: /^hotfix-.+$/
    
Copy the code

when

When is used to determine whether and how the current job will be executed when the current job fails. For example, we want Lint to succeed before we execute build:

build_job:
  when: on_success
  stage: build
  needs: lint_job
Copy the code

Another example is when we want to manually click the publish button to publish:

publish_job:
  when: manual
  stage: publish
  script: npm run deploy
Copy the code

artifacts

In the build job mentioned earlier, we will use webPack to generate compressed, obfuscated code that needs to be saved or downloaded, which is where artifacts come in. Usage:

build_job:
  script: npm run build
  artifacts:
    name: "$CI_COMMIT_REF_NAME"
    paths: dist/
Copy the code

Artifacts are eventually packaged into a compressed file, where path represents the file or folder to be added to the compressed file, and name represents the name of the generated compressed file. Then you can download it from the corresponding task details page:

include

Just as code reuse is achieved through programs and modules, the YML configuration of CI can be achieved through include:

include:
  - remote: 'https://gitlab.com/awesome-project/raw/master/.before-script-template.yml'
  - local: '/templates/.after-script-template.yml'
  - template: Auto-DevOps.gitlab-ci.yml
Copy the code

This way, we can put some common environment variables or jobs into a public REPO and refer to them through Remote in other projects.

tags

We already know that CI tasks are run by runners. So, how do we tell CI what runner is used for each job? Here’s an official example:

windows job:
  stage:
    - build
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

osx job:
  stage:
    - build
  tags:
    - osx
  script:
    - echo "Hello, $USER!"
Copy the code

The example above defines two jobs, one to run on Windows and the other to run on MAC. We add tags to the job, so that CI will find a runner with tags to perform the task.

Finally, github Actions are similar in concept to Gitlab CI, but the configuration is not quite the same. There is also a documentation for migrating- bud-from-gitlab-cicd-to-Github – Actions

Reference: gitlab.com/help/ci/yam…