app-build: drop the push:main leg, keep the PR gate - #1028
Merged
Conversation
The workflow was disabled manually on 21 July. In the eleven days since, 49 commits touched app-target Swift with no compile check at all - swiftc -parse is syntax only, so an orphaned doc comment, a strict-concurrency question and 190 lines of new SwiftUI all reached main unverified. It also runs StrandTests, which executes in no other workflow. A dispatch probe from a ci/ branch at 8560f9a passed both legs in ~5 minutes, so nothing had actually broken in the meantime - it can come back on as-is. Dropping the push:main leg roughly halves what it costs to keep on. Every change reaches main through a PR, which the pull_request trigger already gates, so the push run rebuilt content that had just been built - on a two-runner macOS matrix that GitHub bills at 10x Linux. A release pushes straight to main with no PR, but fork-release.yml builds both Strand and NOOPiOS itself, so that path keeps its own gate. The gap left is a direct non-release push to main, which workflow_dispatch covers on demand.
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.
Re-enables the app-target compile gate at a cost that should be sustainable.
Where this stood
app-build.ymlhas beendisabled_manuallysince 21 July — the YAML was always fine, the workflow was just switched off in the Actions UI. In the eleven days since, 49 commits touched app-target Swift with no compile verification of any kind.That is not theoretical. It cost three near-misses in a single session:
BLEManager.swiftreached main, becausedoc_comment_lint.pydoes not cover app-target Swift and nothing compiled it;[weak bridge]closure in iOS: write to Apple Health when an offload lands, not only on foreground entry (#1021) #1024 had to be cleared by readingSWIFT_STRICT_CONCURRENCYout ofproject.ymlby hand, rather than by building it;swiftc -parseis the strongest local check available, and it is syntax only — no type-checking, no linking.The workflow also runs
StrandTests, which executes in no other workflow. Those tests had not run since 21 July either, including the Swift twins added in #1019.The probe
Dispatched from a disposable
ci/branch at8560f9a1(main's head), so main could not go red:Both legs green in about five minutes,
StrandTestsincluded. Eleven days and 49 commits of drift broke nothing — it can come back on as it stands.What changes
Only the
push: mainleg goes. Every change reaches main through a PR, which thepull_requesttrigger already gates, so the push run was rebuilding content that had just been built — on a two-runner macOS matrix (macos-15for the universal macOS leg,macos-26for the iOS 26 SDK) that GitHub bills at 10× Linux. That roughly halves the cost of keeping the gate.Releases keep their gate. A release pushes straight to main with no PR, but
fork-release.ymlbuilds bothStrandandNOOPiOSitself, so that path is still compile-verified. The gap this leaves is a direct, non-release push to main;workflow_dispatchcovers checking one on demand, and the existingci/-branch convention plus itscleanupjob make that a one-liner.Note
The workflow is enabled as of now — that was a prerequisite for dispatching the probe, since a manually-disabled workflow cannot be dispatched at all. If you would rather it stayed off, disabling it again is one API call and this PR can be closed; nothing here depends on it.