Skip to content

ci: bind version/ref inputs via env before shell in release workflows - #9388

Open
SashaMIT wants to merge 2 commits into
ElementsProject:masterfrom
SashaMIT:ci/bind-release-workflow-inputs-env
Open

ci: bind version/ref inputs via env before shell in release workflows#9388
SashaMIT wants to merge 2 commits into
ElementsProject:masterfrom
SashaMIT:ci/bind-release-workflow-inputs-env

Conversation

@SashaMIT

@SashaMIT SashaMIT commented Aug 6, 2026

Copy link
Copy Markdown

Summary

Follow-up to #9383 (thanks @Andezion for the enumeration). The four workflows feeding the release pipeline still interpolated inputs.version / github.ref_name directly into run: blocks:

  • check-release-tag.yml: echo "version=${{ inputs.version }}", TAG_VERSION="${{ github.ref_name }}", check-release.sh --version=${{ steps...version }}
  • release-build.yml: [[ "${{ inputs.skip_validation }}" == "true" ]], --force-version "${{ inputs.version }}"
  • release-publish.yml: VERSION="${{ inputs.version }}"
  • pypi-build.yml: make update-pyln-versions NEW_VERSION=${{ inputs.version }}

Same class as #9383: GitHub's documented script-injection guidance is to bind workflow inputs through env: before shell use. All four now do.

Also dropped a dead duplicate CHANGELOG_VERSION=${VERSION#v} line in release-publish.yml that executed before VERSION was set.

Left untouched deliberately: if: / name: / with: / tag_name: interpolations (expression contexts, not shell) and ${{ matrix.* }} values (hardcoded in the workflow).

Test plan

  • All four files parse as valid YAML
  • Behavior identical for well-formed versions/tags (same values reach the scripts, quoted)

Made with Cursor

env:
INPUT_VERSION: ${{ inputs.version }}
run: |
CHANGELOG_VERSION=${VERSION#v}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch!

Comment thread .github/workflows/release-publish.yml Outdated

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about this line? As i see keyid comes from crazy-max/ghaction-import-gpg parsing a repo-owned secret, so practical risk is very low, but maybe we should fix this aswell??

@Andezion
Andezion force-pushed the ci/bind-release-workflow-inputs-env branch from 777fe36 to 64e6070 Compare August 6, 2026 18:41
@SashaMIT

SashaMIT commented Aug 6, 2026

Copy link
Copy Markdown
Author

Good spot, thank you. Agreed on the risk assessment: steps.gpg.outputs.keyid is produced by crazy-max/ghaction-import-gpg from a repo-owned secret, so nothing PR-controllable flows through it today.

Bound it via env: anyway (11d8864): the cost is one line, every run: block in the release path now follows the same env-first pattern, and the invariant no longer depends on that action's output staying trusted forever. If you'd rather keep the diff minimal I'm happy to drop the commit instead.

@madelinevibes madelinevibes added this to the v26.09 milestone Aug 7, 2026
SashaMIT and others added 2 commits August 7, 2026 16:34
Follow-up to the docker/pypi env-binding pass: check-release-tag.yml,
release-build.yml, release-publish.yml and pypi-build.yml still
interpolated inputs.version / github.ref_name directly into run:
blocks (script-injection class per GitHub's hardening guidance).

Bind through env: and reference quoted shell variables instead. Also
drops a dead duplicate CHANGELOG_VERSION assignment in
release-publish.yml that ran before VERSION was set.

Made-with: Cursor

Changelog-None
Per review: keyid comes from crazy-max/ghaction-import-gpg parsing a
repo-owned secret, so practical risk is low; bind it anyway so every
run: block in the release path follows the same env-first pattern and
the invariant does not depend on that action's output staying trusted.

Made-with: Cursor
Signed-off-by: SashaMIT <sash.t.mitchell@gmail.com>
@cdecker
cdecker force-pushed the ci/bind-release-workflow-inputs-env branch from 11d8864 to dffc947 Compare August 7, 2026 14:34

@cdecker cdecker left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK dffc947

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants