Group items tagged

docker build --cache-from "$CI_REGISTRY_IMAGE:latest" -t "$CI_REGISTRY_IMAGE:new-tag"

But if you maintain a CHANGELOG in this format, and/or your Git tags are also your Docker tags, you can get the previous version and use cache the this image version.

script: - export PREVIOUS_VERSION=$(perl -lne 'print "v${1}" if /^##\s\[(\d\.\d\.\d)\]\s-\s\d{4}(?:-\d{2}){2}\s*$/' CHANGELOG.md | sed -n '2 p') - docker build --cache-from "$CI_REGISTRY_IMAGE:$PREVIOUS_VERSION" -t "$CI_REGISTRY_IMAGE:$CI_COMMIT_TAG" -f ./prod.Dockerfile .

« Docker layer caching » is enough to optimize the build time.

We're building a Docker image, dependencies are installed inside a container.We can't cache a dependencies directory if it doesn't exists in the job workspace.

Dependencies will always be installed from a container but will be extracted by the GitLab Runner in the job workspace. Our goal is to send the cached version in the build context.

- docker cp app:/var/www/html/vendor/ ./vendor

after_script

- docker cp app:/var/www/html/node_modules/ ./node_modules

To avoid old dependencies to be mixed with the new ones, at the risk of keeping unused dependencies in cache, which would make cache and images heavier.

If you need to cache directories in testing jobs, it's easier: use volumes !

version your cache keys !

sharing Docker image between jobs

In every job, we automatically get artifacts from previous stages.

docker save $DOCKER_CI_IMAGE | gzip > app.tar.gz

I personally use the « push / pull » technique,

use all rules keywords, like if, changes, and exists, in the same rule. The rule evaluates to true only when all included keywords evaluate to true.

use parentheses with && and || to build more complicated variable expressions.

Use workflow to specify which types of pipelines can run.

every push to an open merge request’s source branch causes duplicated pipelines.

avoid duplicate pipelines by changing the job rules to avoid either push (branch) pipelines or merge request pipelines.

For behavior similar to the only/except keywords, you can check the value of the $CI_PIPELINE_SOURCE variable

commonly used variables for if clauses

rules:changes expressions to determine when to add jobs to a pipeline

Use !reference tags to reuse rules in different jobs.

Use except to define when a job does not run.

only or except used without refs is the same as only:refs / except/refs

If you change multiple files, but only one file ends in .md, the build job is still skipped.

If you use multiple keywords with only or except, the keywords are evaluated as a single conjoined expression.

only includes the job if all of the keys have at least one condition that matches.

except excludes the job if any of the keys have at least one condition that matches.

To specify a job as manual, add when: manual to the job in the .gitlab-ci.yml file.

Use protected environments to define a list of users authorized to run a manual job.

Use when: delayed to execute scripts after a waiting period, or if you want to avoid jobs immediately entering the pending state.

To split a large job into multiple smaller jobs that run in parallel, use the parallel keyword

run a trigger job multiple times in parallel in a single pipeline, but with different variable values for each instance of the job.

The @ symbol denotes the beginning of a ref’s repository path. To match a ref name that contains the @ character in a regular expression, you must use the hex character code match \x40.

Compare a variable to a string

Check if a variable is undefined

Check if a variable is empty

Check if a variable exists

Check if a variable is empty

Matches are found when using =~.

Matches are not found when using !~.

Join variable expressions together with && or ||