Repository navigation
Conversation
Move the remaining expression values that were interpolated directly into run: scripts (inputs.tag, github.repository, step outputs, repository owner/name) into env: variables, matching the pattern already used elsewhere in these workflows and GitHub's script-injection guidance. Behavior is unchanged. Fixes WordPress#602
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Pass expression values through environment variables .github/workflows/release-publish.yml, .github/workflows/release-wporg.yml |
The workflows pass repository details, prerelease status, tag input, and resolved version to shell scripts through environment variables. The release download and metadata verification commands remain unchanged. |
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Refactor
Possibly related PRs
- WordPress/sqlite-database-integration#578: It updates release version and changelog data consumed by the release-publish workflow.
Suggested reviewers: janjakes
Merge Risk: 
2cb74
-
The workflow changes preserve release behavior while moving expression values out of shell source, so the PR is mergeable.
Pre-merge checks: 
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled. Title check The title "Pass workflow values via env in release workflows" matches the main change. The PR moves five GitHub Actions expression values from direct interpolation in shell scripts into step-level env… Linked Issues check Directly linked issue #602has five coding requirements. Each requirement is met in the diff from merge base to head:
- release-wporg.yml, "Resolve tag": inputs.tag moved to INPUT_TAG env; script uses…Out of Scope Changes check The diff changes only .github/workflows/release-wporg.yml and .github/workflows/release-publish.yml. Every hunk replaces one of the five expressions named in #602with an env variable reference, or ad…Docstring Coverage No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat… Full details: Title check
-
Explanation
The title "Pass workflow values via env in release workflows" matches the main change. The PR moves five GitHub Actions expression values from direct interpolation in shell scripts into step-level environment variables across release-wporg.yml and release-publish.yml. The title is specific, concise, and names the mechanism and the affected workflows.
Full details: Linked Issues check
-
Explanation
Directly linked issue
#602has five coding requirements. Each requirement is met in the diff from merge base to head:- release-wporg.yml, "Resolve tag": inputs.tag moved to INPUT_TAG env; script uses TAG="$INPUT_TAG". Same value and same normalization logic.
- release-wporg.yml, "Download plugin zip from release": github.repository moved to REPO env; script uses --repo "$REPO".
- release-wporg.yml, "Verify release metadata": steps.resolve.outputs.version moved to VERSION env; script passes "$VERSION" as argument.
- release-publish.yml, "Get contributors from changelog PRs": github.repository_owner and github.event.repository.name moved to REPO_OWNER and REPO_NAME env. The GraphQL QUERY is now a double-quoted string with escaped quotes. It expands to the same text as the previous single-quoted string with interpolated values.
- release-publish.yml, "Create GitHub release": steps.version.outputs.prerelease moved to PRERELEASE env; the test is now [[ "$PRERELEASE" == "true" ]].
All changes use the env pattern already used in these files. The issue has no non-coding requirements that need assessment.
Full details: Out of Scope Changes check
-
Explanation
The diff changes only .github/workflows/release-wporg.yml and .github/workflows/release-publish.yml. Every hunk replaces one of the five expressions named in
#602with an env variable reference, or adds the env: entries that carry those values. No unrelated steps, triggers, permissions, or commands change. The new env entries and shell variable references support the required change and are in scope.
Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.)
-
Finishing Touches
-
Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Summary
Fixes #602.
Pass expression values to
run:scripts throughenv:variables instead of interpolating${{ ... }}expressions directly into the shell script, following GitHub's script-injection guidance and the pattern already used elsewhere in these workflows (BRANCH,VERSION,CHANGELOG, …).Changes, all behavior-preserving (same values, same commands):
release-wporg.yml:inputs.tagviaINPUT_TAGenv var.github.repositoryviaREPOenv var.steps.resolve.outputs.versionviaVERSIONenv var.release-publish.yml:github.repository_owner/github.event.repository.nameviaREPO_OWNER/REPO_NAMEenv vars used in the GraphQL query string.steps.version.outputs.prereleaseviaPRERELEASEenv var.Notes
This is defense-in-depth hardening: today these workflows are only reachable by maintainers (merged
release/*pull requests, manual dispatch), so nothing is exploitable as-is. Moving the values toenv:removes the substitution-before-parsing footgun if inputs, branch naming, or triggers ever change.Both files remain valid YAML and the modified shell snippets pass
bash -n; the GraphQL query construction produces the identical string as before.Summary by CodeRabbit