Feature request/idea: Upstream update merge requests
Problem to solve
Upstream versions change and break things. For example Docker image versions. Or updates are not applied in time, which can be a security update or end up diverging to far from upstream.
Intended users
Developers, Operations, etc.
Further details
Far to often people have to choose between having things breaking because they are following the latest updates or not knowing when a new upstream version exists. Here is an example:
[0] gitlab-runner#4501 (closed)
Proposal
Have a periodic Gitlab system which checks upstream for updates of newest versions like a git repository of an upstream library or docker image tag.
Maybe in case of Docker images it could be as simple as having a Dockerfile with:
image docker:hash
# gitlab-merge-request-on-update: docker:stable
This doesn't seem to conflict with parser-directives:
https://docs.docker.com/engine/reference/builder/#parser-directives
Only deploy the latest version with the hash and don't break things.
If I'm not mistaken Gitlab developers were already working on an automated process to deploy security updates of libraries used by projects based on CVEs. This is similar but more generic.
This seems like it could be a feature of auto-devops.
Permissions and Security
Developers should be able to set this up when configuring their projects.
Documentation
The new feature needs to be documented how to set it up and the merge requests need to be clear on how they were created and why. Possible a name should be determined which can be used for this consistently. For example: upstream update merge-requests.
Testing
What risks does this change pose?
This will prevent things from breaking, but could also be a security problem becauses updates are applied with a delay.
How might it affect the quality of the product?
If it can be automatically merged and CI/CD done than it would be a process improvement. Everything that is deployed in production or CI/CD stages is a known entity, not just a tagged version. But references by hash instead.
What does success look like, and how can we measure that?
Prevent breaking builds so people can keep working uninterrupted. And have full insight in when things change in an production, test/QA, build environments.