ci: validate pull requests before they merge - #16
Merged
Conversation
The workflow only triggered on pushes to main, so a content PR could not be checked until AFTER it merged. That is not hypothetical: #13 merged clean and immediately turned main red, because three spelling issues had no opportunity to surface earlier. Pull requests now run the same checkout / install / spell-check / build steps a deploy runs, and stop before touching AWS. Reusing the one job rather than adding a separate validation workflow means the PR necessarily runs what the deploy will run — a second workflow could drift from it. The three AWS steps are guarded with `github.event_name != 'pull_request'`, so a PR run performs no OIDC exchange, no S3 sync and no CloudFront invalidation. No paths-ignore on the PR trigger, unlike push: skipping a deploy for a change that cannot affect the built site is worthwhile, but skipping VALIDATION is not — a workflow or config change is exactly the kind of thing worth checking on the PR, and the run is cheap. Concurrency is unaffected: github.ref is refs/pull/<n>/merge on a PR, so validation runs get their own group and cannot cancel a deploy of main. Note the id-token: write permission stays declared at workflow level and is simply unused on PR runs. Scoping it to a deploy-only job would need either a second build or artifact passing between jobs; happy to do that if the broader permission on PR runs is a concern. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Change-Id: I5cdc568b682e61723dfe0c2ca2142b660cd1b153
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.
The workflow only triggered on pushes to
main, so content PRs could not be validated until after they merged.That's not hypothetical — #13 merged clean and immediately turned
mainred, because three spelling issues had no opportunity to surface earlier. #15's description had to carry a "merge #14 first" note for the same reason.What changes
Pull requests now run the same checkout / install / spell-check / build steps a deploy runs, and stop before touching AWS.
Reusing the single existing job — rather than adding a separate validation workflow — means a PR necessarily runs exactly what the deploy will run. A second workflow would be free to drift from it.
The three AWS steps are guarded with
github.event_name != 'pull_request', so a PR run performs no OIDC exchange, no S3 sync, and no CloudFront invalidation.Two deliberate choices
No
paths-ignoreon the PR trigger, unlikepush. Skipping a deploy for a change that can't affect the built site is worthwhile; skipping validation isn't. A workflow or config change is precisely what's worth checking on the PR, and the run is cheap.Concurrency is unaffected.
github.refisrefs/pull/<n>/mergeon a PR, so validation runs get their own group and can't cancel an in-flight deploy ofmain.One thing worth your call
id-token: writestays declared at workflow level and is simply unused on PR runs, since every AWS step is skipped. Scoping it to a deploy-only job would require either a second build or passing the build output between jobs as an artifact. Happy to do that if the broader permission on PR runs bothers you — I kept the diff minimal instead.Verified
YAML parses, and the trigger/guard structure is as intended:
This PR should be its own proof: once open, it ought to run the validation job and stop short of deploying.
🤖 Generated with Claude Code