4. Rules and Caching
Introduction
This section will add rules the the pipeline to provide additional controls around when jobs run, as well as caching to speed up jobs that require the same node modules to be downloaded.
Adding Rules
-
1. In your demo project, find the 4-rules-and-caching
branch inCode > Branches
-
2. Next to the branch name, click New
to create a new Merge Request from this branch -
3. Click Create Merge Request
-
4. Review the changes to the .gitlab-ci.yml file: - Two variables,
BUILD_DISABLED
andCODE_QUALITY_DISABLED
, have been added which are used in conjunction with job rules to include or omit certain jobs.- These variables are declared globally and will be available in all jobs.
- The
code_quality
has been updated with therules
keyword specifying that the job will only run in pipelines triggered from commits to the main branch, and only when theCODE_QUALITY_DISABLED
variable is not equal to 'true'.- This is useful for controlling the execution of jobs that may be unnecessary to run for every commit to a feature branch, or control when deploy jobs are ran for various environments.
- Additionally, the allow_failure keyword has been added to the
code_quality
job which allows the job to fail without affecting continued execution of the rest of the pipeline.- The
script
section of the job contains an added command for intentionally failing the job to demonstrate this rule in action.
- The
- The cache keyword has been added as a global definition specifying that any downloaded node modules will be cached between jobs, speeding up pipeline execution since subsequent jobs will not need to download them again.
- The cache is stored by default where the GitLab Runner is installed, but can also be uploaded to S3 if distributed cache is enabled.
- A cache:key keyword is set to the predefined variable
$CI_COMMIT_REF_SLUG
which will share the cache only between pipelines run on the same branch.
- Two variables,
-
5. Within the Merge Request, click Mark as Ready
in the Overview tab (if prompted), then clickMerge
. This will trigger a new pipeline using the newly added configurations to the .gitlab-ci.yml file. -
6. In the left side navigation menu, click Build
->Pipelines,
then click the link for the most recently ran pipeline to view the status of the pipeline. -
7. Within the pipeline graph, observe that the code_quality
job failed with a warning, but the overall pipeline still succeeded. -
8. Click on the unit_test
job and observe in the console output that the cached node modules were available to the job and did not need to be re-downloaded. -
9. Run a pipeline manually on the main branch by navigating in the left-side menu to Build
->Pipeline
, then clicking the Run Pipeline button in the upper right corner. Select themain
branch, then manually change values for theBUILD_DISABLED
andCODE_QUALITY_DISABLED
variables to true. Put the variable name (ex: BUILD_DISABLED) in the "input variable key" box, and the variable value "true" in the "input variable value" box. Click "Run Pipeline", then observe that thebuild_app
andcode_quality
jobs have been omitted from the triggered pipeline.