Four changes, three of them gaps in the filters added by the previous commit.
Go tests execute db/migrations/*.sql for real: persistence_suite_test.go calls
db.Init, which runs goose against an in-memory database. `make migration-sql`
produces a .sql-only diff, and six such commits exist in history, so those PRs
would have run zero Go tests. Added ^db/migrations/ to the Go filter.
validate-translations.sh reads ui/src/i18n/en.json as its reference, not
resources/i18n/en.json, which does not exist. A commit that only removes an
English key (dd4802c0c is one) would have skipped the only check that reports
the orphaned keys left in all 36 translations.
The coverage-artifact probe was unpaginated. A full Go pipeline run produces
exactly 30 artifacts, the API default page size, and octocov-pr sorts to index
27 because the test jobs finish first. Run 33503006884 already produced 33 and
pushed all three coverage artifacts off page one. Server-side ?name= filtering
has no count ceiling.
The script also now fails closed if the base ref cannot be resolved. The fetch
itself stays non-fatal: actions/checkout already created the ref, so a failed
refresh is harmless, and making it fatal would turn a transient blip into a red
pipeline.
Also adds workflow_dispatch, so a manual run is possible and gets every flag.
A new `changes` job diffs the PR against its base branch and emits four
flags (go, js, i18n, build) that gate the steps of the test, lint and build
jobs. A docs-only PR now runs no Go tests and no 11-platform build.
The flags gate steps rather than jobs on purpose: a job-level skip
propagates through the needs chain (actions/runner#491) and would take the
release jobs down with it on tag pushes. Only upload-packages and the
push-manifest jobs skip at the job level, where nothing depends on them.
Master pushes and tags always get every flag, so a release can never be
built from a partially validated tree.
coverage-on-pr.yml now probes for the coverage artifact before downloading
it, since a PR with no Go changes produces none.
* ci: comment coverage on pull requests from forks
A pull_request run from a fork gets a read-only GITHUB_TOKEN, so octocov could not post its comment: it logged a 403 and exited 0, leaving the job green and the PR silent. The 'permissions:' block cannot grant what the token does not have.
The comment now comes from a workflow_run workflow, which runs on the base repository and does get a write token. The pipeline job keeps the job summary and the default-branch baseline, and hands the merged profile and the PR number to it as an artifact.
A workflow_run job otherwise looks like a push to the default branch, so octocov is pointed back at the pull request and at the run that produced the profile via its OCTOCOV_ environment overrides. Without the run id override the test execution time would be read from the wrong run; without the ref override a fork's coverage would be stored as the master baseline.
The job holds a write token, so it reads .octocov.yml from the base branch rather than from the fork.
* ci: stop checking out the fork in the coverage comment workflow
CodeQL flagged the pull request checkout as untrusted code in a privileged context (actions/untrusted-checkout/high): the job holds a write token. The checkout existed only so the code-to-test ratio would reflect the pull request, which does not justify the alert.
The workflow now checks out just .octocov.yml from the base branch, and the ratio is skipped when reporting from there. Coverage and its delta against master, the metrics that motivated the report, are unaffected: they come from the profile the pipeline uploads.
* ci: treat the coverage artifact as untrusted input
A pull_request run executes the fork's own copy of pipeline.yml, so every file in the octocov-pr artifact is attacker-controlled. The artifact was extracted into the workspace root, on top of the base-branch checkout, and download-artifact truncates existing files. A fork could therefore replace .octocov.yml before octocov loaded it.
That is not only a config swap. config.Load expands ${VAR} from the job environment and the action sets OCTOCOV_GITHUB_TOKEN, so a crafted comment.message posts the privileged job's token into a public comment; a body: section rewrites a pull request description, which pull-requests: write allows.
The artifact now lands in a subdirectory and only coverage.out is copied out, after pr_number is checked to be digits and the named pull request's head is confirmed to be the sha that triggered this run. Without that check the artifact could aim the comment at any open pull request, and unvalidated content reached GITHUB_OUTPUT.
