Conversation
Replace two third-party actions (tim-actions/get-pr-commits and tim-actions/commit-message-checker-with-regex) with a few lines of shell using the GitHub API. Listing the PR commits via the API means no checkout is needed at all, so the job takes a couple of seconds. Merge commits are skipped, as their subjects are generated by git and GitHub, not by the contributor. The API output is saved to a file before being fed to jq, rather than piped into it. In a pipeline, a gh failure would be masked, as jq happily succeeds on empty input. With the file, a gh failure fails the step via the default bash -e. The if is kept at the step level rather than the job level, so that the job still succeeds (with its step skipped) for non-PR events. A skipped job would cascade and skip all-done. (cherry picked from commit 23b509a) Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The lumaxis/shellcheck-problem-matchers action merely ships a JSON file and echoes an ::add-matcher:: command, so do that ourselves. Its matcher only annotated warning and error findings. Two reasons: the severity capture group listed (note|warning|error), while shellcheck severities are error, warning, info and style; and the runner honors only error, warning and notice, skipping any other match (see Runner.Worker/Handlers/OutputManager.cs). As info and style are the bulk of what shellcheck reports, most findings were never annotated. Use a fixed severity instead (any finding fails the job anyway), and keep the severity word as part of the message. Note the same applies to the usual gcc-format matchers, as shellcheck -f gcc reports both info and style as "note", which is not "notice". Verified on a test PR: with no matcher, a file with four shellcheck problems produces no annotations at all; with this one, all four are annotated at the right lines. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> (cherry picked from commit 5b10527) Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #5384 to release-1.5. Original description follows.
Two independent cleanups in the
validateworkflow, each replacing athird-party action with a few lines in-tree.
1.
commitjob: simplify the subject length checkReplace two third-party actions (
tim-actions/get-pr-commitsandtim-actions/commit-message-checker-with-regex) with a few lines of shellusing the GitHub API (based off of moby/moby#53327, thanks @thaJeztah!).
No checkout is needed at all, so no source reaches the runner.
Verified on this PR: the job concludes
successin 3 steps and ~3s (downfrom 5 steps and 4s with a shallow checkout), and a temporary commit with a
100-character subject was flagged (and only that one), exiting 1.
2.
shellcheckjob: droplumaxis/shellcheck-problem-matchersThat action does nothing but ship a JSON file and echo an
::add-matcher::command, so we now do that ourselves, with the matcher in
.github/shellcheck-tty.json.Its matcher was also only annotating
warninganderrorfindings, for tworeasons: its severity capture group lists
(note|warning|error), whileshellcheck severities are
error,warning,infoandstyle; and therunner honors only
error,warningandnotice, silently skipping anyother match (
Runner.Worker/Handlers/OutputManager.cs). Asinfoandstyleare the bulk of what shellcheck reports, most findings were neverannotated. Ours uses a fixed severity instead (any finding fails the job
anyway) and keeps the severity word in the message.
Verified on a fork PR, on a file with four shellcheck problems (one
info,one
style, twowarning):exit code 2";
Note that the usual gcc-format matchers have the same problem, as
shellcheck -f gccreports bothinfoandstyleasnote, which is notnotice.