Run the core build on pull requests - #17
Merged
Merged
Conversation
PRs #13 through #16 all merged without a single check running. The three workflows trigger only on push to main, workflow_dispatch, and (for PureData) workflow_run, so nothing gates a merge -- the only verification those PRs got was me dispatching a workflow by hand against the branch. Adding pull_request here closes the most important half of that: every PR is now gated on the core library still building on macOS, Linux and Windows. Left unfiltered on purpose, unlike the push trigger. A PR should be checked whichever directory it touched; the path filters are part of why a puredata- or maxmsp-only change currently triggers nothing at all. The other two workflows deliberately do not get the trigger yet. The PureData workflow reads its core artifact id from github.event.workflow_run, so on a pull_request event CORE_RUN_ID is empty and it fails at its own guard. The Doxygen deploy fails by design pending the organization owner's decision on Pages, and would mark every PR red. Both are resolved by the ci.yml restructure that follows, which replaces the cross-workflow artifact handoff with in-run job dependencies -- and which will itself be reviewed with these checks running. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.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
1 participant
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.
PRs #13–#16 all merged without a single check running. Nothing gates a merge today — the only verification those PRs got was me dispatching a workflow by hand against the branch, which is also how we ended up with a red X that looked real but was an artifact of cross-workflow wiring.
This adds
pull_request:to the core workflow. Every PR is now gated on the core library building on macOS, Linux and Windows.Left unfiltered, unlike the
pushtrigger below it. A PR should be checked whichever directory it touched — the path filters are part of why apuredata/- ormaxmsp/-only change currently triggers nothing at all.Why only this workflow
github.event.workflow_run. On apull_requesteventCORE_RUN_IDis empty, so it would fail immediately at its own "Ensure core artifact id present" guard.docs/design/github-pages-deployment.md), and would mark every PR red.Both are resolved by the
ci.ymlrestructure that follows this PR, which replaces the cross-workflow artifact handoff with in-runneeds:dependencies.Why this is first
It is deliberately small so that the restructure PR gets reviewed with checks actually running on it — including the Windows job, which is the only one that can catch core/wrapper API drift at link time.
This PR validates itself:
pull_requestworkflows run from the PR's merge ref, so the trigger being added here takes effect on this PR.🤖 Generated with Claude Code