stacklok / stacklok/docs-website
Extract the fat inline bash steps from upstream-release-docs.yml into scripts/
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 4
- Forks
- 3
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 41
Description
.github/workflows/upstream-release-docs.yml is 1667 lines across 41 steps, including 960 lines of inline bash. The size is concentrated in four steps:
| Step | Inline bash lines |
|---|---|
| Augment PR body (marker-delimited section) | 313 |
| Assign reviewers and prepare contributor mentions | 121 |
| Resolve release owner and contributors | 99 |
| Capture skill signal files | 74 |
| remaining 37 steps | 353 (avg 9) |
Two reasons to extract the big ones:
- Nothing lints the inline bash. There is no shellcheck or actionlint in CI, so checking a change today means hand-extracting
steps[].runfrom the YAML, stubbing${{ }}, and piping it to shellcheck. scripts/upstream-release/already holds five.mjsfiles and this workflow already invokes one, so a script there inherits Prettier and ESLint from existing CI with no new tooling.
Augment PR body is the best first candidate: its only I/O is roughly 25 env vars in and one gh pr edit --body-file out, and the PR body is the artifact reviewers actually read.
Scope
In:
Augment PR bodytoscripts/upstream-release/render-pr-body.mjsAssign reviewersandResolve release owner and contributorsas separate follow-ups if the first goes cleanly
Out:
- The two Claude step prompts (88 lines). Their content is almost entirely interpolated run context, and the durable instructions already live in the
upstream-release-docsskill. Capture skill signal files, mostly file reads andGITHUB_OUTPUTheredocs.- The 37 short steps, which belong inline.
Sequencing
After #1111 has run live on two or three release PRs. That change is unvalidated, and stacking a refactor on it means a live failure has two candidate causes instead of one.
#1111 and this refactor touch the same steps, so if #1111 needs iteration, extract Augment PR body first (#1111 only added two table rows and two sections to it) and leave the reviewer steps until after validation.
Verification
Behavior-preserving: render the extracted script against the env of a real past run and diff the output against that run's actual PR body.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Read .github/workflows/upstream-release-docs.yml, the Augment PR body step, and the existing files in scripts/upstream-release/. Use the environment from a real past run to compare the extracted script's output with that run's actual PR body; done means behavior is preserved and the script is covered by the existing formatting and linting setup.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- bash, github-actions, javascript
- Domain
- ci-cd, devops, tooling
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 52/100