stacklok / stacklok/docs-website

Extract the fat inline bash steps from upstream-release-docs.yml into scripts/

Open
#1,112 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement github_actions needs-triage
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[].run from the YAML, stubbing ${{ }}, and piping it to shellcheck.
  • scripts/upstream-release/ already holds five .mjs files 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 body to scripts/upstream-release/render-pr-body.mjs
  • Assign reviewers and Resolve release owner and contributors as 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-docs skill.
  • Capture skill signal files, mostly file reads and GITHUB_OUTPUT heredocs.
  • 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.