Publish test-count badges through the documentation site#21
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8e2b31a5a0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| git config user.email 'actions@github.com' | ||
| git add .github/badges | ||
| git commit --quiet -m 'ci: refresh test count badges' | ||
| git push --quiet --force "$remote" HEAD:badges |
There was a problem hiding this comment.
Restrict manual badge publishing to main
When this workflow is run manually with workflow_dispatch on any non-main ref (for example via gh workflow run ... --ref feature-branch, which GitHub supports), the checkout and badge generation use that selected branch's tests but this line still force-pushes the result to the shared public badges branch. A contributor testing a PR branch can therefore overwrite the published badge counts with pre-merge or experimental counts; guard the publish step to refs/heads/main or explicitly check out/count main before updating the shared branch.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
When this workflow is run manually with
workflow_dispatchon any non-mainref ... this line still force-pushes the result to the shared publicbadgesbranch
Good catch, and it is a real hole in that approach (I hit it myself while testing). This PR has since dropped the branch-push design entirely: publish-test-badges.yml is removed, and the counts are generated during the docs deploy and served from the documentation site. There is no shared badges branch any more, so a workflow_dispatch on a feature ref cannot overwrite the published counts.
The badge-refresh workflow pushed regenerated counts to main, which the branch ruleset blocks for the Actions token, so the published numbers went stale. Generate the three test-count JSON files during the documentation deploy and serve them from the published site, so refreshing the badges needs no push to a protected branch. The shields.io endpoint URLs point at the site, the standalone publish workflow is removed, and the stale on-main copies are dropped.
8e2b31a to
5e625a7
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5e625a767e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - run: zensical build --clean | ||
| - name: Add test-count badges to the site | ||
| run: | | ||
| pip install ".[develop]" |
There was a problem hiding this comment.
Fetch tags before installing the package
On normal main pushes where HEAD is not itself a release tag, the docs workflow's default actions/checkout is a depth-1 checkout without tag history, but this newly added install now builds a package whose version is derived by setuptools-scm (dynamic = ["version"] with no fallback in pyproject.toml). The deleted badge workflow used fetch-depth: 0 before this same install; without restoring that here, pip install ".[develop]" can fail version detection before tools/generate_test_badges.py runs, so the docs/badge deployment remains broken. The setuptools-scm docs also call out using fetch-depth: 0 for GitHub Actions: https://setuptools-scm.readthedocs.io/en/latest/integrations/
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
without restoring [
fetch-depth: 0] here,pip install ".[develop]"can fail version detection beforetools/generate_test_badges.pyruns
Added fetch-depth: 0 to the docs checkout, thanks. One correction for the record: the build does not actually fail without it. I tested a depth-1, no-tags checkout, and setuptools-scm falls back to a 0.0.post1.dev1+g<sha> version and the wheel builds fine; since the badge step only runs pytest --collect-only, the counts are unaffected by the version string. The full fetch is still the right call (it yields the real version and matches the setuptools-scm guidance), just not a deploy-breaker.
The docs deploy now installs the package to count tests for the badges, and setuptools-scm reads the version from git tags. A shallow checkout has none, so it falls back to a 0.0.post dev version; fetch the full history so the build resolves the real version.
|
@codex review |
|
Codex Review: Didn't find any major issues. Bravo. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
nichollsh
left a comment
There was a problem hiding this comment.
Nice catch. Seems like compiling the badges during the documentation workflow will be more consistent. Personally, I would prefer uploading them to a Gist so that the workflow doesn't have to make any modifications to the GitHub repo directly, but this is a fine alternative.
Description
The test-count badges regenerate from
pytest --collect-only, but the old refresh workflow pushed the new JSON back tomain, which the branch ruleset blocks for the Actions token. The push failed and the published counts drifted out of step with the suite: the badge read 126 tests while collection now reports 338.This serves the badges from the documentation site instead of a protected branch. The documentation deploy (
docs.yaml) regenerates the three JSON files after building the site and writes them intosite/badges/, so they ship with the existing GitHub Pages deployment. The shields.io endpoint URLs point at the site, the standalone push-to-main workflow is removed, and the stale on-maincopies are dropped. No branch push, no token, no ruleset bypass.No issue number; surfaced by the failing "Refresh test count badges" check on the latest
main.Validation of changes
sitemap.xml,objects.inv,assets/*all return HTTP 200), sobadges/tests-*.jsonresolves athttps://proteus-framework.org/CALLIOPE/badges/.tools/generate_test_badges.py: total 338, unit 215, integration 123 (the committed copies were 126 / 96 / 30).docs.yamlparses as valid YAML and that no/main/.github/badges/or publish-test-badges references remain in the tree.The published badge URL resolves once this merges and the documentation redeploys.
Tested on macOS with Python 3.12.
Checklist