README: state the sandbox role, and why this repo is not the release gate - #52
Merged
Merged
Conversation
…gate This repo is where actions features get tried end to end -- PR-scoped build caching (#36), PDF and notebook builds in preview (#35), the @v0 migration (#26). That role was never written down, so it was read as the release gate, which it cannot be. Three properties make a red run here ambiguous: a floating :latest container, Dependabot enabled, and an @v0 pin that always exercises the previous release rather than a candidate. The first two are the right properties for a sandbox -- they are how upstream breakage surfaces early -- and exactly wrong for a gate. Gating moves to a separate frozen fixture, test-actions-release. See QuantEcon/actions#136 for the split and QuantEcon/actions#135 for the gate mechanism. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Clarifies this repository’s role relative to quantecon/actions: it is an experiment/integration sandbox and post-release canary, not the release-gating fixture, and explains why those roles must be split.
Changes:
- Reframes the repo purpose as an integration sandbox + canary for
quantecon/actions. - Documents why this repo cannot serve as a release gate (moving container, Dependabot drift, floating
@v0). - Points readers to
test-actions-releaseand the upstream issues for the gating split.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
📖 Netlify Preview Ready!Preview URL: https://pr-52--jade-tarsier-d98a19.netlify.app Commit: Build Info
|
"always exercises the previous release" reads as perpetually one version behind, which is false -- @v0 tracks the current release, so once the tag moves this repo is on the new code like everyone else. "Previous" only holds in the narrow window relative to a candidate at gating time. The accurate statement is also the stronger one: this repo only ever exercises a published release, never a candidate, and because a release moves the tag, consumers arrive at the new code at the same moment it does. That names both the missing candidate coverage and the missing lead time -- which together are the reason gating needs a separate staging tag rather than a schedule change. Raised by Copilot on #52. 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.
Writes down what this repo is for. The role was never stated, so it was read as the release gate — which prompted QuantEcon/actions#136.
What it is
The experiment and integration sandbox for
quantecon/actions, plus its post-release canary. The question it answers is does this work against a real-ish lecture repo? Its history is exactly that: PR-scoped build caching (#36), PDF and notebook builds in CI preview (#35), the@v0migration (#26).What it is not
The release gate. Three properties make a red run here ambiguous, and the first two are the right properties for a sandbox — they are how upstream breakage surfaces early:
quantecon-build:latest@v0Those are contradictory repo-level settings, which is why one repo cannot hold both roles. Gating moves to
test-actions-release— QuantEcon/actions#136 for the split, QuantEcon/actions#135 for the mechanism.Note on the existing trim
While writing this I audited the fixture and initially claimed it does build-time network reads. That was wrong and I have corrected it upstream:
only_build_toc_files: truemeans only the five lectures in_toc.ymlbuild, and they were chosen against explicit criteria including no network access. Verified — the built set has zero remote reads. PR #49 had already done that work.One real gap did surface: the built set has no plotly, so kaleido static export is uncovered — the QuantEcon/actions#85 failure path. Not addressed here; noted in QuantEcon/actions#136 as cheap to add.
Docs only.
🤖 Generated with Claude Code