Cleanup/Simplify/Speed up CI config
Description
I'd like to revisit the CI config. Specific things I'd like to look at:
-
Use caching patterns and terminology already established from vs code fork and www-gitlab-com repo. -
Use the naming conventions and reliability/speedup tweaks also used in those repos. -
Abstract build commands into a single reusable YAML anchor, then have MR pipelines only build, whilemain
branch pipelines build and deploy. This is the same pattern used in https://gitlab.com/gitlab-org/project-templates/static-site-editor-middleman/-/blob/master/.gitlab-ci.yml, and speeds builds by avoiding the passing of artifacts between builds, and the need to spin up 2 jobs instead of 1 in themain
pipeline.- NOTE: Didn't end up needing this, there's only a single build job, and we are going ahead with the standard pattern of passing along the build artifacts to the publish and deploy jobs.
-
On MR branches, run test stage jobs in parallel with build (because there's no deploy, there's no reason not to parallelize it) -
I'd like to understand why check_ci.sh
is needed, and if we can avoid it through Makefile/CI config tweaks. -
Do we really need our own dedicated Dockerfile (see detailed question in comment here: #9 (comment 1038349752)) -
Turn on Merge Trains
MRs
- Polish CI (!28 - merged)
- More polish/cleanup for CI config and workflow (!30 - merged)
- Additional CI fix and pipeline speed optimization (!31 - merged)
Results
- We are now using standard patterns established in other existing pipelines such as
www-gitlab-com
andgitlab-web-ide-vscode-fork
- MR pipelines are fast - as fast as 1 minute 9 seconds - when the runner has the docker image cached and not blocked by the docker image download (which takes about 45 second).
-
main
branch pipelines are running in 3 minutes or less, and would be close to 2 minutes if the docker image were cached on all runners. This is compared to a ~5 minute runtime prior to the CI polishing. About 2+ minutes improvement on average.
Edited by Chad Woolley