<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=21178) </details> <!--IssueSummary end--> ### 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.