commitlint job fails for MRs which are not directly branched from current main

In MRs we use CI_MERGE_REQUEST_DIFF_BASE_SHA in the --from option for commitlint. When this base SHA is not the current tip of development, commitlint fails silently which is confusing:

See, e.g. https://gitlab.developers.cam.ac.uk/uis/devops/experiments/rjw57/gitlab-utils/-/jobs/1763888

A workaround is to make sure the MR is based on the current main branch but it is non-obvious that this is a workaround.

added issuetypeBug teamCloud labels

mentioned in merge request uis/devops/infra/terraform/gcp-cloud-run-app!88 (merged)

added uis/devops/hr#36 as parent epic

@ad2139 or @rjw57, this has impacted a few within teamHolberton recently. Would it be possible to dedicate some time to investigating this, and if we don't have a route to an immediate fix it'd be good to do some comms and document this issue so it's more widely known.

This also caused issues in teamIdentity, where we actually decided to not use the commitlint CI template anymore because of this issue (and because we thought having commitlint in pre-commit would do the same, but @rjw57 told me that's not the case). I am now doing a tour in the DA team and they told me they also have issues with this, and actually work around it by rebasing all the time.

This is especially problematic in very active repositories, where over the course of working on a branch, multiple changes are merged into the default branch while working on the branch.

One of the big issues is also that it's unclear why it fails, as there is barely any information why it fails.

Yes, this is a wart and needs fixing. I'll pick this up today to see if I can at least get a better error message out of commitlint. Tagging @rk725 as the original implementor in case they have input.

assigned to @rjw57

mentioned in commit 639ad80d

mentioned in merge request !124 (merged)

@wgd23, @st981 - I wonder if you'd mind looking at !124 (merged) which I believe should fix this problem. On investigation there were a couple of nits which needed fixing:

• We used git merge-base --fork-point to determine which commit we should start linting from. This would exit with a non-zero exit code in the cases highlighted in this issue which, in turn, caused the commitlint job to fail mysteriously with no error. !124 (merged) handles the non-zero exit code case gracefully.
• The use of --fork-point might not quite match what GitLab uses. Looking at the original discussion around commitlint it would appear that not using --fork-point better aligns with GitLab's own algorithm.

I tested !124 (merged) by making a trivial branch off an older commit and reproduced the reported commitlint behaviour (job log). Using the job from !124 (merged) fixes the issue (job log).

Thank you for looking into this. The changes make sense to me, so I approved it.

Thanks. I've merged and tagged. Let me know if that allows you to re-enable the CI jobs.

I've created uis/devops/iam/activate-account/frontend!88 (merged) for a repository in teamIdentity and https://gitlab.developers.cam.ac.uk/uis/devops/digital-admissions/pools/smi/-/merge_requests/151 for a repository in DA to spread awareness around the teams that this bug has been fixed.

Might be worth sharing that this is fixed in the Teams discussion too?

I was hoping to get positive confirmation that is is fixed before shouting too loud :). If it is fixed, then do please disseminate the information.

added quick to review workflowReview Required labels

changed iteration to Cloud Team Sprints Mar 26, 2025 - Apr 8, 2025

mentioned in commit 6514d0b1

closed with merge request !124 (merged)

mentioned in merge request uis/devops/iam/activate-account/frontend!88 (merged)