What needs to be done?
contribute-to-celo/release-process/smart-contracts.mdx hand-copies yarn release:* script names and their flags from celo-monorepo/packages/protocol, and nothing checks that they still exist. #2295 found four names on the page that no longer resolve (release:verify-deployed, release:make, release:check-versions, release:verify-release); packages/protocol/package.json on master defines only release:check-versions, release:check-versions:foundry, release:make:foundry, release:verify-deployed:foundry, release:check-opcodes and release:determine-release-version. The names went stale silently because the page has no link to the source of truth that would have been checked, and no test.
#2295 fixes the names and links RELEASE_PROCESS_FOUNDRY.md, which gives the page an anchor but not a test. This issue is the test.
Impact: a release engineer following the page runs a command that fails with "command not found" at best. One surviving name, release:check-versions, is worse: it still exists in package.json but calls a build_tag function that release-lib.sh no longer defines, so it passes a grep and dies before compiling. Wrong data on a page that drives a mainnet governance proposal.
Suggested fix, pick one:
- A CI check that extracts every
yarn release:<name> and getopts flag from the page's code blocks and verifies them against packages/protocol/package.json and the release/*.sh getopts strings at celo-monorepo master. A small script under scripts/, run in the existing link-check workflow, failing on any name or flag that does not resolve.
- If a cross-repo check is too heavy, a recurring task (quarterly, matching the release cadence) that re-verifies the page against upstream, with the check commands recorded on the page in an HTML comment so the next person runs the same thing.
Non-goal: rewriting the release process itself. Depends on #2295 merging first so the check starts from a green page.
Refs #2295.
Definition of done
Priority
medium
Size
S — hours
What needs to be done?
contribute-to-celo/release-process/smart-contracts.mdxhand-copiesyarn release:*script names and their flags fromcelo-monorepo/packages/protocol, and nothing checks that they still exist. #2295 found four names on the page that no longer resolve (release:verify-deployed,release:make,release:check-versions,release:verify-release);packages/protocol/package.jsononmasterdefines onlyrelease:check-versions,release:check-versions:foundry,release:make:foundry,release:verify-deployed:foundry,release:check-opcodesandrelease:determine-release-version. The names went stale silently because the page has no link to the source of truth that would have been checked, and no test.#2295 fixes the names and links
RELEASE_PROCESS_FOUNDRY.md, which gives the page an anchor but not a test. This issue is the test.Impact: a release engineer following the page runs a command that fails with "command not found" at best. One surviving name,
release:check-versions, is worse: it still exists inpackage.jsonbut calls abuild_tagfunction thatrelease-lib.shno longer defines, so it passes a grep and dies before compiling. Wrong data on a page that drives a mainnet governance proposal.Suggested fix, pick one:
yarn release:<name>andgetoptsflag from the page's code blocks and verifies them againstpackages/protocol/package.jsonand therelease/*.shgetoptsstrings atcelo-monorepomaster. A small script underscripts/, run in the existing link-check workflow, failing on any name or flag that does not resolve.Non-goal: rewriting the release process itself. Depends on #2295 merging first so the check starts from a green page.
Refs #2295.
Definition of done
yarn release:*name on the page is verified against upstream by a script or a recorded recurring checkPriority
medium
Size
S — hours