task: verify release-process script names and flags against celo-monorepo instead of hand-copying them
- Dominant language
- MDX
- Stars
- 90
- Forks
- 382
- Avg merge
- 3d 9h
- Merged PRs (30d)
- 35
Description
### 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:
1. A CI check that extracts every `yarn release:` 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.
2. 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
- [ ] Every `yarn release:*` name on the page is verified against upstream by a script or a recorded recurring check
- [ ] The check fails (or the task flags) when a name or flag on the page no longer exists upstream; proven once by breaking a name locally
- [ ] Owner and cadence recorded on the page or in the workflow
### Priority
medium
### Size
S — hours
Contributor guide
Research direction
Start with contribute-to-celo/release-process/smart-contracts.mdx, then inspect the existing link-check workflow and the release sources in celo-monorepo/packages/protocol/package.json and release/*.sh. Build the check around the page's yarn release:* names and getopts flags, and verify it fails for a deliberately broken name or flag while recording the owner and cadence.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, shell
- Domain
- ci-cd, documentation, release
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 68/100