Skip to content

ci: run every workflow on merge to main, except the release - #272

Merged
eaitbrahim merged 1 commit into
mainfrom
ci/trigger-on-merge
Aug 15, 2026
Merged

ci: run every workflow on merge to main, except the release#272
eaitbrahim merged 1 commit into
mainfrom
ci/trigger-on-merge

Conversation

@eaitbrahim

Copy link
Copy Markdown
Contributor

The repository became public on 2026-08-15. GitHub bills no Actions minutes for standard runners on public repositories, so the cost argument that kept code-quality and migrate off push no longer applies.

Final trigger set

workflow triggers on merge to main?
ci.yml pull_request, push [main], workflow_dispatch yes (unchanged)
code-quality.yml push [main], schedule, workflow_dispatch new
migrate.yml push [main], workflow_dispatch new
release.yml workflow_dispatch no — deliberately

release.yml stays manual

By explicit instruction, and it could not work otherwise: its version input is required, a push event supplies no inputs, so the job would fail at its first validation step. Its own header already states the rule — "Nothing about a money-moving tool should ship on a merge."

The safety property that makes migrate on push sound

This is a property of the event, not of anyone's care. db_path is a workflow_dispatch input; a push carries no inputs, so on a merge ${{ inputs.db_path }} renders empty and the job always takes its migration_smoke.py branch. No merge can supply a value that makes it write to a real database. The comment says so, and says not to add a default target or read one from a repo variable — either would remove the property.

code-quality keeps its schedule, and still has no pull_request

The weekly run is kept rather than replaced: a CVE published against an unchanged pin is invisible to a per-merge trigger and obvious to a scheduled one.

pull_request remains absent, and on a public repo that is now a security choice rather than a cost one — fork PRs receive no repository secrets, so every one would fail at the preflight for a reason the contributor cannot fix.

⚠️ Known consequence

SONAR_TOKEN and SNYK_TOKEN do not exist at repo or org level, so code-quality will fail its preflight on every merge until they are added. That job exists to say why in one line rather than let the scanners fail obscurely — but it will now say it on every merge rather than once a week. Add the two secrets, or say the word and I will make the preflight skip cleanly instead of failing red.

🤖 Generated with Claude Code

The repository became PUBLIC on 2026-08-15. GitHub bills no Actions minutes
for standard runners on public repositories, so the cost argument that kept
`code-quality` and `migrate` off `push` no longer applies. Both now also run
on merge to `main`; `ci` already did.

`release.yml` stays `workflow_dispatch` only, deliberately and by the
operator's explicit instruction. Its own header states the rule -- "Nothing
about a money-moving tool should ship on a merge" -- and it could not run on
`push` anyway: its `version` input is required and a push event supplies no
inputs, so the job would fail at its first validation step.

`migrate.yml` gains a safety property worth naming, because it is a property
of the EVENT rather than of anyone's care: `db_path` is a `workflow_dispatch`
input, and a push carries no inputs, so on a merge `inputs.db_path` renders
empty and the job always takes its `migration_smoke.py` branch. No merge can
supply a value that makes it write to a real database. The comment says so,
and says not to add a default target or read one from a repo variable, since
either would remove the property.

`code-quality.yml` keeps its weekly schedule rather than replacing it: a CVE
published against an unchanged pin is invisible to a per-merge trigger and
obvious to a scheduled one. It still does NOT run on `pull_request`, and on a
public repo that is now a security choice rather than a cost one -- fork PRs
receive no repository secrets, so every one would fail at the preflight for a
reason the contributor could not fix.

KNOWN CONSEQUENCE: SONAR_TOKEN and SNYK_TOKEN do not exist at repo or org
level, so `code-quality` will fail its preflight on every merge until they
are added. That job exists to say why in one line rather than let the
scanners fail obscurely, but it will now say it on a schedule of every merge.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@eaitbrahim
eaitbrahim merged commit 1de7c5e into main Aug 15, 2026
1 check passed
@eaitbrahim
eaitbrahim deleted the ci/trigger-on-merge branch August 15, 2026 20:31
eaitbrahim added a commit that referenced this pull request Aug 15, 2026
…atched (#276)

`code-quality` has failed on every merge to `main` since #272 added the `push`
trigger. The cause is exactly what the job was written to report:

    Missing: SONAR_TOKEN SNYK_TOKEN
    ##[error]Process completed with exit code 1

Neither secret exists at repo or org level, so the preflight exits 1 and both
scans are skipped. Nothing is broken in the code -- the workflow is correctly
telling us it is not configured.

WHY THAT ANSWER STOPPED BEING RIGHT. Failing loudly was correct when this ran
weekly and on dispatch: an unconfigured repo produced one red X every Monday,
and the message named the missing secrets instead of letting Sonar and Snyk
fail with their own unhelpful auth errors. #272 added `push: [main]`, and the
same behaviour now means `main` is permanently red for a condition that is not
a defect. A red X on every merge is worse than a missing scan: it is a signal
the reader learns to ignore, and it hides the next real failure.

WHAT CHANGES. The preflight now reports rather than decides, and who asked
determines the verdict:

  workflow_dispatch  -> a human asked for a scan. Still FAILS, loudly.
                        Silently doing nothing in response to a direct request
                        is the worse outcome, so that path is unchanged.
  push / schedule    -> nobody asked. Skips both scans, writes the missing
                        secrets and where to get them to the run summary, and
                        emits a ::notice. The build stays green.

The two scan jobs are gated on a `configured` output rather than a condition
written on them directly, because `secrets` cannot be referenced from a
job-level `if:`.

The skip is announced, never silent -- same standard the rest of this repo
holds discovery to. A scan that did not run and says so is honest; one that
quietly does nothing is not.

Verified by running the preflight script directly in all three states: push
without tokens exits 0 with `configured=false` and a correctly rendered
summary; dispatch without tokens exits 1; either event with both tokens exits
0 with `configured=true`.

This does not add the secrets. Once they exist the scans run and none of the
above applies.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant