The README tells consumers to pin the v1 tag, and no workflow tests main #58
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The README describes a release process the repository does not follow, and the checks run on pull request heads only, so the merge result that consumers pin is never tested by a workflow.
The README names a tag nobody pins
The Release section says to move the
v1tag to the new bundle commit and that "consumers pin the action atv1" (README.md:165-167). This repository's own review workflow pins a full commit SHA (.forgejo/workflows/review.yml:81), and the pin updates land as commits such as "chore: update review wrapper pin". The repository has no tags, so thev1tag the section moves and tells consumers to pin does not exist.The section should describe what happens: merge to
main, then pin the merge commit's full SHA. A moving tag is the weaker pin, and the wrapper's security notes assume the pinned bundle is the reviewed one.No workflow runs on
mainchecks.ymltriggers onpull_requestandworkflow_callonly (.forgejo/workflows/checks.yml:5).commit-msg.ymlruns on pull requests.dedupe-check.ymlruns on pushes tomain, but only whenpnpm-lock.yamlchanges. The test suite, including the test that rebuilds the bundle and compares it with the committeddist/index.mjs, never runs on a merge result.Consumers run
dist/index.mjsat a commit onmain. A squash merge produces a tree that no check saw whenevermainmoved after the pull request's last run, and nothing would show it.Add
push: branches: [main]to the Checks workflow. The file's header says a standalone repository renders it, so it may be generated byj4k-align. If so, the trigger belongs in the template that renders it.🤖 Generated with Claude Code