PMX: Give main its own sanity check and rename the CI workflow - #7
Merged
Merged
Conversation
- `🔁 CI` becomes `🧪 Pull Request Checks` — the file only ever runs pull-request checks, so the name should say so - drop the `push: branches: [main]` trigger — the existing comment already notes `pull_request` covers branch pushes, so it was dead scope - job id/name `checks`/`🔍 Checks` becomes `pull-request-checks`/ `🚦 Pull request checks` to match the file rename
- `pull-request-checks.yml` sets `concurrency: cancel-in-progress: true` unconditionally — a rapid second push to `main` can cancel the first push's check run with no completed record left behind - new `✅ Sanity check` workflow runs on `push: branches: [main]` only, with `cancel-in-progress: false`, so every push to `main` gets a completed run - runs `bun run system-check` — `format:check`, `build:types`, `lint`, `test`, `build:vite` — the same full gate as pull requests - `deploy.yml` already builds, tests, and deploys on push to `main`, but gives no standalone "is `main` healthy" signal independent of the deploy pipeline
✅ Deploy Preview for thepokemax ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
- `🧪 Pull Request Checks` becomes `🧪 Pull request checks` to match the sentence-case convention used across workflow `name:` fields
- the file rename should not have touched the job — `pull-request-checks`/ `🚦 Pull request checks` reverts to `checks`/`🔍 Checks`, verbatim from `main` - only the top-level workflow `name:` was meant to change, and it stays `🧪 Pull request checks` - `on:` trigger changes are unaffected — the dropped `push: branches: [main]` scope stays dropped
sanity-check.yml and finish CI renamemain its own sanity check and rename the CI workflow
- bare `push:` was unscoped, which is the `branches: ['**']` case the file's own comment warned about — every commit on this branch ran the workflow twice, once per event (runs `33989796613` and `33989799860` on `d56814b`) - `on:` is now `pull_request:` alone, so pull request checks never run on `main` — `sanity-check.yml` owns that signal - `workflow_dispatch:` dropped: a manual run of PR checks outside a pull request has no branch to check against - the comment above `concurrency` is deleted rather than reworded — the double-run condition it described no longer exists
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.
Splits CI into the two questions it was conflating: does this pull request pass, and is
mainhealthy. The renamedpull-request-checks.ymlnow answers only the first, and a newsanity-check.ymlanswers the second — a signal the current setup can silently lose.pull-request-checks.yml.github/workflows/ci.ymlrenamed to.github/workflows/pull-request-checks.yml— the file only ever ran pull-request checksname:goes from🔁 CIto🧪 Pull request checkson:is nowpull_request:alone —push:andworkflow_dispatch:are gone, so pull request checks never run onmainconcurrencyis deleted rather than reworded — it described a double-run condition that no longer existschecksand job name🔍 Checksare unchanged frommainsanity-check.yml✅ Sanity checkworkflow, triggered onpush: branches: [main]onlybun run system-check—format:check,build:types,lint,test,build:vitecancel-in-progress: false, wherepull-request-checks.ymlsetscancel-in-progress: trueunconditionally — a rapid second push tomaincan cancel the first push's run and leave no completed record for that commit$GITHUB_STEP_SUMMARYnaming the short SHAdeploy.ymlalready builds, tests, and deploys on push tomain, but gives no "ismainhealthy" signal independent of the deploy pipelineVerification
0cb7770—gh run listshows a singlepull_requestrun, against two runs each (pull_request+push) for every earlier commit on this branch🔍 Checksgreen on this PR, confirming the job id and name still resolve after the file renamebun run system-checkgreen locally on each push via the pre-push hook —oxfmt --checkon 129 files,tsc -b,oxlint, 143 tests passed / 2 skipped,vite buildgit diff main...HEAD --stattouches exactly two files;deploy.ymlis untouchedsanity-check.ymlhas not executed yet — it triggers only on push tomain, so it first runs when this mergesNotes
branches: [main]scope, leavingpush:unscoped — thebranches: ['**']case the old comment warned about. It ran🧪 Pull request checkstwice on every commit, once per event (runs33989796613and33989799860ond56814b). Restrictingon:topull_requestresolves itworkflow_dispatch:was dropped alongsidepush:— a manual run of pull request checks has no pull request to checkmainworkflow, by request