GitLint action fails with obscure message about broken tool link about util_libs HOT 5 CLOSED

It's possible that this is because GitHub has been upgrading the Ubuntu version their runners are using.

We should probably move away from using Ubuntu-latest, and stick to some LTS version. It has breaking changes way too often.

from util_libs.

The last commit ID might be the merge commit to master which implicitly exists for a mergeable PR. Will look into it.

from util_libs.

In fact, no, the gitlint action takes that into account and doesn't look at that merge commit. 944aa3f is just the commit ID that you had forced-pushed a bit earlier:

axel-h force-pushed the axel-h:axel-patch-1 branch from ecbaba8 to 944aa3f 7 hours ago
..
axel-h force-pushed the axel-h:axel-patch-1 branch from 944aa3f to c906ced 7 hours ago

So my guess is that this is just a race condition. By the time the action was started (which sets all the input environment, revisions etc), 944aa3f was the PR head, and by the time it had installed python etc, 944aa3f had disappeared to be replaced with c906ced. This is rare/unlucky for short checks, but we've seen it quite a few times with long-running checks such as in verification. If you rebase+merge there before some long-running test has run, it might fail just because the revision doesn't exist any more due to the rebase.

ps: the revision has not really disappeared, but it will not be included in a git clone, because it is not connected. It might be possible to script something that fetches an isolated revision, I'm not sure about that.

from util_libs.

Ok, so the weird error messages are fixed, and I've made a note to look into the race condition if that can be avoided in the future. For now, things should be working fine (modulo that occasional race condition -- you should only see these for out-of-date checks, not for the checks that are triggered e.g. by/after a push).

from util_libs.

Apologies, should have checked more closely about the commit ID and should have guessed on my own that this likely comes form the race condition that arises force-pushes. I thint there is no really a nice solution here to avoid this race condition, unless ever script can work on the same repo snapshot. But as soon as you have checker jobs running on other machines also and just pass on the commit ID, they can run into this. I think that is an acceptable thing that one just understand - and aborting there save a lot of CPU time, as there is no point to try to run checks on a commit that got overwritten anyway in a dev branch.

from util_libs.