Skip to content

Construct release URLs from the tag instead of the draft html_url#170

Merged
jesserockz merged 1 commit into
mainfrom
jesserockz-2026-481
Jul 17, 2026
Merged

Construct release URLs from the tag instead of the draft html_url#170
jesserockz merged 1 commit into
mainfrom
jesserockz-2026-481

Conversation

@jesserockz

Copy link
Copy Markdown
Member

Summary

Follow-up to #168, fixing a fleet-wide defect surfaced by a review on esphome/serial-proxies: shipped manifests carry ota.release_url values like https://github.com/esphome/serial-proxies/releases/tag/untagged-48a68f5b50a03b2b1927, which 404.

The root cause is not the tag-reset failure the workflows already guard against: a draft release's html_url always points at an untagged-* placeholder until the release is published, even when its tag_name is healthy (verified live: the current esphome/infrared-proxies draft has tag_name: 26.7.2 but an untagged-* html_url). So every firmware built against a draft, and every manifest patched at publish time, baked in a URL that 404s the moment the release goes live.

Since the final URL is deterministic from the tag, construct https://github.com/<repo>/releases/tag/<tag> instead of reading .html_url, in both places that emit it:

  • build-to-draft-release.yml determine-version (the URL baked into the firmware)
  • publish-draft-release.yml resolve step (the URL patched into the *.manifest.json assets before publishing)

No per-repo fixes are needed: converting the fleet to these workflows fixes the defect going forward. Manifests on already-published releases keep the broken URL until each repository's next release.

A draft release's html_url always points at an untagged-* placeholder
until the release is published, so both the URL baked into the firmware
and the one patched into the manifests 404'd once the release went
live. The final URL is deterministic from the tag, so build it.
@jesserockz
jesserockz merged commit 9f6577f into main Jul 17, 2026
26 checks passed
@jesserockz
jesserockz deleted the jesserockz-2026-481 branch July 17, 2026 09:21
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.

1 participant