docs: point at the renamed canary repo, disambiguate the local clone - #121
Merged
Merged
Conversation
QuantEcon/test-lecture-python-intro is renamed to
QuantEcon/test-actions-lecture-intro so its relationship to this repo is
legible from the name. It is not a fork of lecture-python-intro — it is a
purpose-built canary ("Test repository for QuantEcon Actions", created
2025-11-05) that wires the full chain: restore-jupyter-cache, build-lectures
across all three builders, preview-netlify, build-jupyter-cache and
publish-gh-pages. The last two have no in-repo coverage and are not testable
in-repo, so this is where they get exercised.
The rename also removes a real collision. TESTING.md documents a git-ignored
LOCAL directory of almost the same name — a throwaway clone of the production
lecture-python-intro for manual testing, never committed and read by no
workflow. Two things one character apart, one a live repo and one a scratch
directory, is a trap; that section now says which is which.
PLAN.md's consumer table additionally flags that the canary is pinned @v0.6.0
(Feb 2026, five releases stale) and dormant, so the row is not read as live
coverage. Rehabilitation is #100 stage 2.
GitHub redirects the old name, so existing clones and links keep working
until something else claims it.
Refs #100
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Updates repository documentation to reflect the rename of the stage-2 canary repo and to reduce confusion between the canary repository and a similarly named local, git-ignored test fixture directory.
Changes:
- Update
TESTING.mdreferences fromtest-lecture-python-intrototest-actions-lecture-intro, and add explicit disambiguation between the local fixture directory and the live canary repo. - Update
PLAN.mdconsumer table to use the renamed canary repo name and flag it as stale/dormant at@v0.6.0.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| TESTING.md | Renames canary-repo references and adds clearer wording distinguishing the local ignored fixture dir from the live canary repository. |
| PLAN.md | Updates the production-consumers table row to point at the renamed canary repo and annotate its status. |
… ignored Copilot caught a self-contradiction in the previous commit: the new note said "pick one that does not shadow a real repo" while the documented example was still `test-lecture-python-intro/` — which is the canary's old name and still resolves to it by GitHub redirect. Advice and example disagreed in the same paragraph. Rather than pick a different scratch name, introduce `tests/` as a real home for test infrastructure, with `tests/local/` git-ignored for throwaway clones. A path under `tests/local/` cannot collide with a repo name, so the whole class of confusion goes away instead of being renamed around. It also gives future tooling somewhere obvious to land instead of accumulating at the repo root. `tests/README.md` maps where test assets actually live — the PR harness and its fixture, the container tests, the ignored scratch area, and the canary repo. Nothing is moved: fixtures a workflow consumes stay next to that workflow so the `paths:` filters keep working. The README says so, so the next person does not "tidy" them into tests/ and silently break harness triggering. The legacy `test-*/` ignore pattern is retained, so existing local clones stay ignored where they are. Refs #100 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mmcky
added a commit
that referenced
this pull request
Aug 5, 2026
…116 item 5) (#124) * ci(harness): decide relevance in a gate job, not with paths: filters Prerequisite for making `Action harness: all checks` a required check on main (#116 item 5). A `paths:` filter suppresses creation of the workflow RUN, not just its jobs, so no check run is ever published for that commit and a required check sits in "Expected — waiting for status to be reported" forever. GitHub documents this directly ("Troubleshooting required status checks", Handling skipped but required checks): a workflow skipped by path filtering blocks merging, whereas a job skipped by a conditional reports Success. We saw it live — release PR #119 touched only CHANGELOG.md and GitHub reported "no checks reported on the branch"; docs PR #121 likewise ran nothing. Note #116 item 5's own suggestion — a companion workflow with negated paths — does not work: `paths-ignore` is not the complement of `paths`, so a PR touching both covered and uncovered paths fires BOTH workflows and produces two same-named check runs on one SHA. That case is the norm here, not an edge case. So: both `paths:` filters go, the workflow always runs, and a `gate` job decides relevance. Only the four root jobs take `needs: gate`; everything else already chains off them, and a job whose needs were skipped is itself skipped. The decision rule is an IGNORE list, not a cover list, and that direction is the point. For a required check the expensive mistake is a green earned by running nothing, so anything unrecognised — a new action directory, a new fixture — runs the whole harness. A cover list would invert this: forgetting to extend it would silently rubber-stamp untested action changes, where today the same omission blocks the merge. The gate also self-tests. It derives the must-always-run set from the `uses: ./<action>` lines in the workflow itself, so a typo that widened IGNORED to swallow a real action path fails the gate closed rather than skipping the suite — which harness-summary would otherwise accept as a legitimate shape. Deriving it from the workflow means future coverage (e.g. publish-gh-pages) is protected with no second edit. Permissions are job-scoped, not workflow-scoped: on a fork pull_request the other jobs run PR-authored composite-action code via `uses: ./`, and none of them needs a pull-request scope. harness-summary is rewritten to certify both shapes — all-ran and all-skipped — to reject a vacuous empty job set, and to fail when the gate and the fan-out disagree. Verified locally before pushing, by extracting both scripts from the YAML and running them against mocked inputs: the gate over the real file lists of #119 and #121 (both correctly irrelevant), an action change, a fixture change, a workflow_dispatch, push with no before-SHA, a compare 404 from a force-push (fails open), a gh API error (fails closed), and a deliberately widened IGNORED (fails closed with the self-test error). The summary was exercised across all ten reachable shapes. Refs #116 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci(harness): anchor the gate self-test to real step invocations The first CI run of this PR reported: gate self-test passed; harness invokes: build-jupyter-cache build-lectures publish-gh-pages restore-jupyter-cache setup-environment publish-gh-pages is not invoked by the harness. The unanchored grep was matching the action name out of the gate's own COMMENT, which mentioned `uses: ./publish-gh-pages` as an example of future coverage. Harmless in effect — the extra entry only enlarges the must-run set, so it fails safe — but it made the self-test assert something other than what it appears to, which is precisely the failure mode this job exists to prevent. Anchoring to the start of a line counts only real step invocations. Caught by reading the job's own output rather than by a test, which is worth noting: the self-test cannot detect this class itself. Refs #116 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(tests): correct the harness job breakdown Copilot review. The line claimed "a relevance gate plus 15 jobs exercising ... via uses: ./ local paths", which implies harness-summary exercises actions. It does not — it invokes nothing and only certifies the others. The real shape is the gate, 14 action-invoking jobs, and the summary. Verified against the workflow rather than counted by hand. Refs #116 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Docs-only. Follows the rename of
QuantEcon/test-lecture-python-intro→QuantEcon/test-actions-lecture-intro.Why rename it
It reads as a fork of⚠️ TEST REPOSITORY / 🧪 This is a test repository for QuantEcon Actions development / Do not use for production purposes". The new name makes the relationship to this repo legible without opening it.
lecture-python-intro. It isn't —fork=false, created 2025-11-05, purpose-built, and its README opens with "It matters more than cosmetics because of what it covers. It wires the full chain —
restore-jupyter-cache,build-lecturesacross all three builders,preview-netlify,build-jupyter-cache,publish-gh-pages— and the last two have no in-repo coverage and are not testable in-repo (a composite action is all-or-nothing, souses: ./publish-gh-pagesdies atconfigure-pagesand never reaches the release-asset code). This repo is where they get exercised, and it was easy to miss.The collision this removes
TESTING.md documents a git-ignored local directory of almost the same name — a throwaway clone of the production
lecture-python-introfor manual testing, never committed, read by no workflow. Two things one character apart, one a live repo and one a scratch directory, is a trap. I walked into it myself while reviewing #116 and initially reported the local directory as committed repo bloat. That section now states plainly which is which.What else changed
PLAN.md's consumer table now flags that the canary is pinned@v0.6.0(Feb 2026, five releases stale) and dormant, so the row is not read as live coverage. Itscache.ymlandlinkcheck.ymlaredisabled_inactivity, and its last runs are red — CI Preview failed 2026-07-15, Build Cache failed 2026-04-12, with nobody watching. Rehabilitation is #100 stage 2 and is not in this PR.Blast radius
GitHub redirects the old name, so clones and links keep working until something else claims it. Verified after the rename: the old path still resolves, Pages moved to
https://quantecon.github.io/test-actions-lecture-intro/, andNETLIFY_SITE_IDis intact (it is an ID, not a name).One reference lives outside this repo —
QuantEcon/workflow-backupsconfigs/config.quantecon-all.yml:104lists the old name in a backup exclusion list under# ----- Test repos -----. Left unfixed the renamed repo drops out of that exclusion and starts being archived to S3. Separate one-line PR to follow.Note on CI
This PR touches only
PLAN.mdandTESTING.md, neither of which is in the harnesspaths:filter, so no harness run will appear — the same behaviour release PR #119 showed. Expected, and the reason #116 item 5's gate job has to land before branch protection.Refs #100
🤖 Generated with Claude Code