Enable CI to know if it is processing a Revert commit
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
When code is being reverted, this sometimes means that we are returning a repository to a known good state. For persons that leverage the GitOps model, this has increased value as CI might be performing actions against infrastructure. In the case of the DevOps model, we may be reverting a change that is effectively rolling back code that has been deployed.
Currently, CI has no mechanism to understand if a proposed Revert is actually a revert of any kind. Instead CI will see this as a standard commit and a normal pipeline setup by that user will run as desired. However, there are times when reverting code could be considered standard practice and the desire to revert quickly may be warranted in some cases. Therefore, I propose that we enable GitLab to have knowledge as to whether or not it is starting a CI pipeline on a commit that is part of a revert.
Doing so would provide further control of GitLab CI such that we can eliminate some useless jobs from a lengthy pipeline to enable a revert to occur faster. This varies depending on pipeline setup, and whether or not a project runs merged pipelines, etc. The goal here would be to enable us to expedite reverts, but still keeping in my the safety. So having something that CI can leverage would be beneficial.
Proposal
I'd like to propose that we populate a CI variable with this knowledge. Perhaps something like CI_IS_REVERT and it would be true/false. This would enable users of CI to activate rules or when clauses as desired.