8000
Skip to content

[ci] Name release runs after the version or dev tag they build - #18110

Merged
jesserockz merged 4 commits into
devfrom
jesserockz-2026-543
Aug 9, 2026
Merged

[ci] Name release runs after the version or dev tag they build#18110
jesserockz merged 4 commits into
devfrom
jesserockz-2026-543

Conversation

@jesserockz
@jesserockz jesserockz commented Aug 5, 2026
Copy link
Copy Markdown
Member

What does this implement/fix?

Gives the release workflow a run-name, so the Actions list shows which version each run is publishing instead of the workflow name for every entry. Production and beta releases are named after the release tag (just the version number, e.g. 2026.8.0 or 2026.9.0b1), and nightly dev builds are named after the dated dev tag they build, e.g. 2026.8.0-dev20260806.

A workflow run name is fixed when the run is created and can only reference the github, inputs and vars contexts. There is no date function, no way to read the version out of esphome/const.py, and no API to rename a run afterwards, so the dev tag cannot be worked out by the run name itself. The nightly cron therefore moves into a small new workflow that reads the version, appends today's UTC date, and starts the release workflow with that tag as an input. The release workflow uses the input for both the run name and the tag it builds, so the title always matches what was published.

The tag is still worked out inside the release workflow when no input is given, so a manual run (including one on a branch, which keeps the -<branch> suffix and branch-build behaviour) works exactly as before. Those runs are named Manual build (<branch>).

The new workflow needs actions: write to start the release workflow. GITHUB_TOKEN is explicitly allowed to trigger workflow_dispatch runs.

Types of changes

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • New developer-facing feature (adds functionality for component developers; no end-user configuration change)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected) — policy
  • Developer breaking change (an API change that could break external components) — policy
  • Undocumented C++ API change (removal or change of undocumented public methods that lambda users may depend on) — policy
  • Code quality improvements to existing code or addition of tests
  • Other

Related issue or feature (if applicable):

  • N/A

Pull request in esphome.io with documentation (if applicable):

  • N/A

Pull request in developers.esphome.io with developer documentation (if applicable):

  • N/A

Test Environment

  • ESP32
  • ESP32 IDF
  • ESP8266
  • RP2040/RP2350
  • BK72xx
  • RTL87xx
  • LN882x
  • nRF52840

Example entry for config.yaml:

# Example config.yaml

Checklist:

  • The code change is tested and works locally.
  • Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

@jesserockz
[ci] Name release runs after the version or dev tag they build
a36159c 
A workflow run name is fixed when the run starts and can only use the
github, inputs and vars contexts, so it cannot read the version file or
today's date. Move the nightly cron into its own workflow that works out
the dated dev tag and starts the release workflow with it, and name the
run after that tag. Release runs keep showing just the version number.
@jesserockz
Merge remote-tracking branch 'origin/dev' into jesserockz-2026-543
8c1f02b
@jesserockz
jesserockz requested a review from a team as a code owner August 5, 2026 23:04
Copilot AI lite review requested due to automatic review settings August 5, 2026 23:04
@esphome esphome Bot added github-actions Pull requests that update GitHub Actions code medium-pr PR < 100 lines labels Aug 5, 2026
@esphome
esphome Bot commented Aug 5, 2026
Copy link
Copy Markdown
Contributor

👋 Hi there! This PR modifies 2 file(s) with codeowners.

@esphome/core - As codeowner(s) of the affected files, your review would be appreciated! 🙏

Note: Automatic review request may have failed, but you're still welcome to review.

Copilot AI reviewed Aug 5, 2026
View reviewed changes
Copilot AI left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR improves GitHub Actions usability for releases by naming release workflow runs after the version/tag they publish, and introduces a dedicated nightly workflow to compute the dated dev tag and dispatch the release workflow with that tag.

Changes:

  • Add a run-name to the release workflow to surface the published tag/version in the Actions run list.
  • Add a workflow_dispatch input (tag) so the release workflow can be run with an explicit tag (used by nightly dispatch).
  • Split the nightly cron into a new workflow that computes the dated dev tag and triggers release.yml via workflow_dispatch.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
.github/workflows/release.yml Adds run-name and an input tag, and updates tag selection logic to prefer the provided tag.
.github/workflows/release-nightly.yml New scheduled workflow that computes the dated dev tag and triggers the release workflow with it.
Suppressed comments (1)

.github/workflows/release.yml:37

  • This env assignment uses ${{ inputs.tag }}, but the inputs context is not available when the workflow is triggered by the release event (and can error with "Unrecognized named-value: 'inputs'"). Use github.event.inputs.tag so release-triggered runs don't break.
        env:
          INPUT_TAG: ${{ inputs.tag }}

Comment thread .github/workflows/release.yml Outdated
@esphbot
esphbot commented Aug 6, 2026 •
edited
Loading
Copy link
Copy Markdown
Contributor

Previous review — superseded by a newer review below.

esphbot
esphbot suggested changes Aug 6, 2026
View reviewed changes
@esphbot esphbot left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Warning

Important issues found.

  • Explicit tag input bypasses the -<branch> suffix, letting a branch build publish over latest/stable/dev

@jesserockz
[ci] Read the dispatch tag from github.event.inputs
d3c9551 
Works on every trigger the workflow has, so there is no doubt about the
run name on a release-triggered run.
@esphbot
esphbot commented Aug 6, 2026 •
edited
Loading
Copy link
Copy Markdown
Contributor

Previous review — superseded by a newer review below.

esphbot
esphbot suggested changes Aug 6, 2026
View reviewed changes
@esphbot esphbot left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Warning

Important issues found.

  • Explicit tag input bypasses the -<branch> suffix, letting a branch build publish over latest/stable/dev

swoboda1337
swoboda1337 previously approved these changes Aug 6, 2026
View reviewed changes
@jesserockz
[ci] Only accept the tag input on dev
31021f2 
The tag input was used as given, so a build started from a branch with an
explicit tag lost the branch name that keeps it out of the release
channels, and could publish over the dev, beta, latest and stable images.
@jesserockz
jesserockz requested a review from esphbot August 9, 2026 21:35
@esphbot
esphbot commented Aug 9, 2026
Copy link
Copy Markdown
Contributor

PR Review — [ci] Name release runs after the version or dev tag they build

The blocking issue from the last round is fixed — merge-ready with three non-blocking notes.

Specific things done well:

  • The previous 🟡 is genuinely closed. An explicit tag on a non-dev branch now errors out with ::error:: + exit 1 rather than silently skipping the -<branch> suffix, so a branch build can no longer push latest/stable/beta/dev. I re-checked the gating: deploy-docker and deploy-manifest are still gated only on github.repository (lines 79, 153), so the guard in Get tag is doing the whole job — and it does it.
  • The error message explains why the restriction exists (branch tags must carry the branch name so they cannot publish over channel images), which is the part a future maintainer would otherwise have to reconstruct.
  • Hoisting the date computation into the dispatching workflow also removes a latent midnight-crossing bug: the tag is now stamped once, so a run that starts at 01:59:59 and reaches Get tag after 02:00 can no longer build under a different date than the one it was scheduled for.
  • The nightly guards its version read (::error:: + exit 1 on an empty match) instead of dispatching a date-only tag, and scopes actions: write to the single job that needs it.
  • Re-verified that moving nightly from schedule to workflow_dispatch changes no job gating: deploy-pypi gates on event_name == 'release', version-notifier on branch_build, and schedule appears nowhere else in the file.

Remaining points, all non-blocking:

  • 🟢 The tag input is guarded by branch but not by shape — a dispatch on dev with a bare 2026.8.0 still classifies as the release channel and would push latest/stable from dev code. A regex check on the input closes it in three lines.
  • 🟢 The version + date derivation now exists in both workflows, so a future format change applied to one would silently split manual and nightly dev tags.
  • 🟢 release-nightly.yml has no workflow_dispatch, so the new dispatch path cannot be tested before the first live cron; stale.yml already pairs the two triggers.
  • 🟢 [pre-existing] The release tag and prerelease flag are still interpolated into the shell body, one step below the env: pattern this PR introduces.

✅ Resolved since last review (1)

Previously-flagged issues verified fixed
  • .github/workflows/release.yml:52 Explicit tag input bypasses the -&lt;branch&gt; suffix, letting a branch build publish over latest/stable/dev

🟢 Suggestions

1. [Pre-Existing Issue] Release tag and prerelease flag are still interpolated straight into the shell body
.github/workflows/release.yml:42-44

${{ github.event.release.tag_name }} and ${{ github.event.release.prerelease }} are expanded by the Actions template engine directly into the run: script, so the tag text becomes shell source. A tag containing shell metacharacters would execute inside this job.

This predates the PR and the practical risk is low — only maintainers can publish a release — so it is not this PR's blocker. Two things make it worth repeating while the step is open:

  • The PR introduces the correct pattern four lines above (env: INPUT_TAG: then "${INPUT_TAG}"), so the step is now internally inconsistent about it.
  • needs.init.outputs.tag feeds deploy-manifest's Generate short tags block (line 201), and that value can now originate from a dispatch input rather than only from const.py + date. Still write-access-gated, so no new privilege boundary — just one more caller of the existing pattern.

Giving RELEASE_TAG / IS_PRERELEASE the same env: treatment closes it in the same edit.

TAG="${{ github.event.release.tag_name}}"
BRANCH_BUILD="false"
if [[ "${{ github.event.release.prerelease }}" = "true" ]]; then

Checklist

  • Branch builds cannot publish channel Docker tags (previous blocker)
  • Nightly tag format unchanged (version + UTC date)
  • Existing job gating unaffected by schedule -> workflow_dispatch
  • run-name expression valid for every declared trigger
  • Dispatch input validated before use
  • No untrusted input interpolated into shell — suggestion ＃1
  • Least-privilege workflow permissions
  • No duplicated source-of-truth logic
  • New workflow path is testable before it runs live
  • Diff matches PR description, no scope creep
  • yamllint compatible (line-length disabled in .yamllint)
ℹ️ Triage summary

2 pre-existing finding(s) on unchanged code suppressed (freeze).

Automated review by Kōan (Claude) HEAD=31021f2 3 min 54s

esphbot
esphbot approved these changes Aug 9, 2026
View reviewed changes
@esphbot esphbot left a comment
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Tip

No blocking issues found — ready to merge.

@jesserockz
jesserockz merged commit 989dbd7 into dev Aug 9, 2026
30 checks passed
@jesserockz
jesserockz deleted the jesserockz-2026-543 branch August 9, 2026 22:10
@github-actions github-actions Bot locked and limited conversation to collaborators Aug 11, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

Copilot code review Copilot
Copilot review effort
Applies to this pull request for everyone.Learn more about Copilot code review.
Copilot left review comments
@bdraco bdraco bdraco approved these changes
@swoboda1337 swoboda1337 swoboda1337 left review comments
+1 more reviewer
@esphbot esphbot esphbot approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

github-actions Pull requests that update GitHub Actions code medium-pr PR < 100 lines

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@jesserockz @esphbot @bdraco @swoboda1337
0