GitLab CI Build Dependencies
Description
Many GitLab CI jobs assemble Docker images using Dockerfiles and associated artifacts in GitLab, and when those files are pushed to GitLab, it initiates CI jobs. So far, so good.
What I'm interested in is a way to express other dependencies that should initiate a build that are not in the repository. For example, if my Dockerfile has a FROM debian:latest
, it would be helpful if I could express that dependency to GitLab CI in such a way that it could periodically evaluate the dependencies, and if they've changed, initiate certain jobs.
Proposal
Include a section of build dependencies in the .gitlab-ci.yaml
file. In this section, developers would provide a template to build a dependency map using scripts. Helper scripts for common use cases could be provided by GitLab.
This section could look like this:
build-dependencies:
- dockerParent: image_id_of_parent(Dockerfile)
In this case, the image_id_of_parent
function could be provided by GitLab (if deemed common enough), or some other source the developer provides. It would return at build time a string representing the version of the dependency, in this case a Docker image ID of the image specified in the FROM
line(s) of the Dockerfile.
The build-dependencies
section would be evaluated periodically build time and could be used to determine if which job(s) should be initiated. If any of the values for a build dependency had changed, jobs could be run. Individual jobs could determine which dependency changes could or could not initiate them, similar to the way jobs can be initiated or suppressed by the branch that changed.
This allows developers to have CI that responds to changes external to the GitLab repository, and enables greater build automation.