Prevent commits without ticket reference

[opendevstack]

Prevent commits without ticket reference

[clemensutschig]

@michaelsauter - Part of this is also the shared lib fix of Image labels

[ungerts]

Can you please explain the shared lib fix of image labels in more detail?

[michaelsauter]

@ungerts See opendevstack/ods-jenkins-shared-library#65.

[clemensutschig]

@ungerts fixed now?

[clemensutschig]

@ungerts - where is this fix? @stitakis - do you remember? .. this one we need badly? .. and I remember to have seen it?!

[michaelsauter]

I don't know of anything that enforced a link to a Jira ticket. What "fix" are you referring to?>

[clemensutschig]

So there is a plugin - https://github.com/sford/yet-another-commit-checker that allows exactly this ... we should take a look at it.

[stitakis]

I can't remember that I looked into this. Sorry!

The plugin description looks promising and it is available for installation in the Atlassina Marketplace.
Apart from it I found 2 commercial plugin that we could consider (also availabe over the Atlassian Marketplace):
Jira Hook for BitBucket: https://devopssystems.atlassian.net/wiki/spaces/JHFS/overview
Better Commit Policty for BB: https://www.midori-global.com/products/better-commit-policy-for-bitbucket/server/

[michaelsauter]

Alright, I have been thinking about this one :)

At the most basic level, we want every commit to have a reference to a Jira ticket. So the obvious thing would be to have a Jira ID somewhere in every commit message. E.g. for a project FOO, we have FOO-123 in a commit message to express that this commit relates to issue 123. Using the branch name as a reference is not an option - while Jira can do the connection while the branch exists, the commit may end up on other branches and we cannot trace it any longer.

Anyway - if we have the Jira ticket in the commit message, we can simply add a check in the shared library that fails if there is no reference. This would be very similar to the "ci skip feature", so should be trivial to implement.

However, I see the following problems with above approach:

• There's an initial commit, which has not ticket reference. I think we need to exclude that commit from the check (probably by checking if there is a parent, e.g. git show --no-patch --format="%P" <commit hash>.
• There might be merge commits, which have no ticket reference either. Merge commits might exist because PRs are not merged with --ff-only or if one re-integrates e.g. release branches with the main development branch. The easiest solution I see here is to exclude merge commits (also via git show --no-patch --format="%P" <commit hash> - if there are two parents, it's a merge). Right now I don't see a way to prevent that someone sneaks in unwanted changes into a merge commit, without disallowing merges. Doing that would work when fast-forward is enforced, but it would mean that re-integration must be done via cherry-picking, which is cumbersome.
• There are automated commits in the orchestration pipeline, and they also have no ticket reference. As far as I am aware, there are three types of automated commits right now: 1) exporting OpenShift resources, 2) writing of the deployment descriptor and 3) re-integration into the main branch. Personally, I believe that (1) has no place in a compliant environment: it basically defeats the whole purpose of enforcing a Jira ticket reference. If you want traceability, you cannot sneak changes to your "infrastructure" in without telling who did what exactly when and for which reasons. This commit does not happen if you define infra yourself, so right now I see this a requirement if you want to enforce traceability. (2) is a tricky problem - maybe it would have been better to store the image SHAs outside the repo (e.g. Nexus). For now the only solution I see is excluding this specific commit from the check, which suffers the same traceability issues mentioned above. Finally, (3) is a merge commit and would be already solved by excluding merge commits as suggested earlier.

With that said, we might give this approach (verify every commit, but have exclusions for all problems outlined above) a shot in our next initiative. Then we can gather some real-world experience how much pain enforcing this really is.

FYI @clemensutschig @stitakis @martsec @metmajer @renedupont