Repository navigation
Conversation
A required check and the merge queue both need a result that always reports. The pull_request path filter meant a docs-only pull request got no Shared Server fixtures result at all, so the workflow could not be required. - Pull requests now run the workflow without a path filter. A short `changes` job applies the push trigger's path list to the pull request's merge commit (renames count on both sides), so one list governs both triggers. Push, merge_group and manual runs run every fixture job, as does any pull request that cannot be classified. - `published-sdk-adapters` runs only when the classifier says so; the other fixture jobs need it, so they skip with it. - A terminal `Shared Server fixtures result` job runs with always(). It passes only when every fixture job passed, or when no input changed and every fixture job was skipped. A failed, cancelled or unexpectedly skipped job, a failed classifier, or an unreadable needs context fails it. - ServerParityAggregateTest covers the workflow structure, the result decisions and the classifier against scratch pull request merge commits. Repository contracts runs it. No permissions, secrets, actions or artifact paths change. Making the result a required check, and enabling the merge queue, stay separate repository-setting steps.
The Docker workflow isolation policy accepts only literal .sh and .py repository helpers in workflow steps, so the new jobs' direct node calls failed Public Boundary. changes.sh and aggregate.sh now run the Node scripts from the repository root, as the workflow does, and the classifier tests go through changes.sh.
Member
Author
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.
Part of #325. Stacked on #725 (which is stacked on #723); retargets to
mainafter both merge.Why
A required check, and GitHub's merge queue, need a result that always reports. Shared Server fixtures had a
pull_requestpath filter, so a pull request that touched no fixture input got no result at all. That made the workflow impossible to require, and it is one of the two merge-queue activation prerequisites in #725 (the other is Security's Sonar gate).Change
Pull requests run without a path filter. A short
changesjob applies thepushtrigger's path list to the pull request's merge commit. One list governs both triggers. Renames count on both sides (--no-renames), so moving a fixture out of the corpus still runs the fixtures.push,merge_groupand manual runs run every fixture job.Fixture jobs are gated once.
published-sdk-adaptersruns only whenchangessays so. Every other fixture job needs it and has no job-level condition, so they skip with it.One terminal result.
Shared Server fixtures resultruns withalways(), so it reports after failures and cancellations too. It passes only when:It fails on any failed, cancelled or unexpectedly skipped job, a failed or missing classifier, an unknown decision, no fixture jobs, or an unreadable
needscontext.No permissions, secrets, actions or artifact paths change. Making this result a required check, and enabling the merge queue, stay separate repository-setting steps for Security.
Evidence
changes.shandaggregate.sh, which run the Node scripts from the repository root. The repository's Docker workflow isolation policy accepts only literal.shand.pyhelpers in steps. The first head callednodedirectly and failed Public Boundary for that reason.tests/Unit/ServerParityAggregateTest.mjs(Repository contracts runs it): 26 tests. They cover the workflow structure, every result decision, both wrappers, and the classifier against scratch pull-request merge commits. In those, a docs-only change skips, a Rust change runs, a fixture moved out of the corpus runs, a mismatched head runs, and push, merge_group, manual and unnamed events run. Local: 33/33 withMergeGroupTriggersTest.mjs, innode:22-bookwormas UID 1000.success(), or droppingpostgres-storagefrom itsneeds, fails the structure test.f086ab720: the central action policy validator (.githubmain), the Docker workflow isolation policy and its 72 tests, the public boundary self-test, and the boundary scan of this branch's range all pass.server-parity.yml, so its own run exercises therun=truepath. Therun=falsepath gets its first hosted run on the next docs-only pull request after merge.Trust note
On
pull_request, the workflow, classifier and result script come from the pull request, as every job in this workflow already does. A pull request could edit them to skip fixtures. That is unchanged from today, where it could edit the path filter or the jobs, and any change to these files still runs the full fixture matrix, because the workflow file andscripts/conformance/server-parity/**are in the path list.Security class: R2 (required-check coverage and workflow event handling).