On the roadmap. The tool already produces a summary and a badge; what is missing is the one-line integration that puts them somewhere people look. Attaching the summary to a release is the smallest version of that, and it is a good fit because a release is already a moment where a repository publishes a claim about itself.
Done when
- An Action that runs the tool on the repository and adds its summary to the release body or attaches the report JSON as a release asset. Which of those, or both, is your design call; say why in the pull request.
- It works on a shallow clone or explains clearly that it does not. This is the failure everyone hits first:
actions/checkout fetches one commit by default, and every figure here is computed from history. Whatever you do, the Action must not silently produce numbers from a truncated history.
- It is pinned and least-privilege, matching the other workflows in
.github/workflows, which pin actions to commit SHAs and request the narrowest token they can.
- The README shows the YAML someone can paste, and it is under ten lines.
Out of scope. Publishing anything outside the repository, any hosted service, and any network call other than what the Action needs to talk to GitHub.
The privacy line matters here. This tool exists so people can prove work in private repositories without showing code. An Action that leaks a path, a filename or a commit message into a public release body would break that promise. Check what your summary contains before you attach it.
Taking this on: comment and it is yours, so two people do not write the same patch. No design document needed unless the issue asks for one.
What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat. CONTRIBUTING.md has the rest.
On the roadmap. The tool already produces a summary and a badge; what is missing is the one-line integration that puts them somewhere people look. Attaching the summary to a release is the smallest version of that, and it is a good fit because a release is already a moment where a repository publishes a claim about itself.
Done when
actions/checkoutfetches one commit by default, and every figure here is computed from history. Whatever you do, the Action must not silently produce numbers from a truncated history..github/workflows, which pin actions to commit SHAs and request the narrowest token they can.Out of scope. Publishing anything outside the repository, any hosted service, and any network call other than what the Action needs to talk to GitHub.
The privacy line matters here. This tool exists so people can prove work in private repositories without showing code. An Action that leaks a path, a filename or a commit message into a public release body would break that promise. Check what your summary contains before you attach it.
Taking this on: comment and it is yours, so two people do not write the same patch. No design document needed unless the issue asks for one.
What gets a pull request rejected here: a change with no test; a new runtime dependency; or a number written into a README or a document that did not come from a run somebody else can repeat.
CONTRIBUTING.mdhas the rest.