Skip to content

COMP: Detect a workflow that can never be scheduled - #94

Open
hjmjohnson wants to merge 1 commit into
ci/windowsfrom
ci/workflow-trigger-lint
Open

hjmjohnson wants to merge 1 commit into
ci/windowsfrom
ci/workflow-trigger-lint

Conversation

@hjmjohnson

Copy link
Copy Markdown
Member

Re-submission of #83, reverted from master on 2026-09-24 so it can be
reviewed before merging. Content is unchanged from the original.

Stack position 10 of 10. Base: ci/windows (#82), not master.
Merge the PRs above it in this stack first, or the diff shown here will
include their commits too.

Ordering for this stack

# PR branch base
1 #29 ci/install-linking-srcdir master
2 #28 ci/test-output-on-failure ci/install-linking-srcdir
3 #30 ci/guard-cmp0169 ci/test-output-on-failure
4 #75 ci/build-all-codepaths ci/guard-cmp0169
5 #77 ci/widen-coverage ci/build-all-codepaths
6 #37 pr/fix-missing-prototypes ci/widen-coverage
7 #78 fix/buildyml-jobs pr/fix-missing-prototypes
8 #81 ci/missing-declarations fix/buildyml-jobs
9 #82 ci/windows ci/missing-declarations
10 #83 <- this PR ci/workflow-trigger-lint ci/windows

The order is the order these changes sat on master before the revert, so
it is known to build and test at every step. Verified again after
rebuilding the stack: the tip configures, compiles with no errors, and
passes 344/344 tests.

Why this one is stacked rather than independent

Each PR in this chain edits the same few files as its predecessors, chiefly
.github/workflows/cmake-multi-platform.yml, cmake/exported_symbols_linux.txt
and cifti/afni_xml.h. Cherry-picked onto master alone, the later ones
conflict. Two members also carry a build-order dependency rather than a
textual one: without #30 the project does not configure at all on CMake
versions that do not know policy CMP0169, and #29 is needed for
install_linking to find its source directory.

Commits
  • COMP: Detect a workflow that can never be scheduled

See #84 for the ordering of all 49 re-submitted pull requests.

A branch filter naming a branch that does not exist leaves the workflow
configured but never run, which looks the same as one that runs and
passes: no red check appears because no check appears at all. build.yml
sat dead behind a filter naming main on a repository whose branch is
master, and the only thing that found it was reading the file.

The check judges a filter only when every entry is a literal name, so a
release-* pattern or a branch that does not exist yet is left alone, and
it reports a name that resolves to nothing rather than one that merely
differs from the default.

(cherry picked from commit db038e9)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants