Problem:
The existing release update process automation is a bit fragile today and will break when we have V1 and V2 releases happening concurrently.
Why?
Today what happens is:
- we click "publish" and a release goes live with no assets
- "release published" webhook fires, but IO ignores them because assets aren't ready
- the asset build workflow kicks off, assets get built then uploaded as artifacts to the release
- "workflow job completed" webhook fires, IO receives it
- IO does not know which release or semver this is related to (that info is in "release" webhooks, not "workflow job" webhooks)
- IO naively fetches the latest release from github and assumes it is correct
- IO sets the semver related to that release as the new "current"
This is almost always correct today, where we only have on version line getting released, and releases are spaced out in time.
When we are releasing V1 and V2 lines, and often enough we'll release them concurrently for shared bugfixes, this will break down.
Describe the solution you'd like
Use this release workflow instead:
- prepare a draft release but do not publish it the standard way
- dispatch a workflow job that:
- builds the assets
- attaches the assets to the draft release
- publishes the release
IO can then listen for the "release published" webhook, knowing the assets are already attached to it. It can then extract the release semver from the webhook payload and import and bump the appropriate assets and semver.
Alternative
There appears to be a "prerelease" status for releases (maybe this is what is meant by "draft"? i don't know), perhaps the proposed workflow job could be automatically triggered by that release status.
The final ergonomics of releasing might not follow my proposal, the main goal is having the "release published" webhook fire ONLY after all assets are attached.
Context
workflow job completed webhook payload
release published webhook payload
Problem:
The existing release update process automation is a bit fragile today and will break when we have V1 and V2 releases happening concurrently.
Why?
Today what happens is:
This is almost always correct today, where we only have on version line getting released, and releases are spaced out in time.
When we are releasing V1 and V2 lines, and often enough we'll release them concurrently for shared bugfixes, this will break down.
Describe the solution you'd like
Use this release workflow instead:
IO can then listen for the "release published" webhook, knowing the assets are already attached to it. It can then extract the release semver from the webhook payload and import and bump the appropriate assets and semver.
Alternative
There appears to be a "prerelease" status for releases (maybe this is what is meant by "draft"? i don't know), perhaps the proposed workflow job could be automatically triggered by that release status.
The final ergonomics of releasing might not follow my proposal, the main goal is having the "release published" webhook fire ONLY after all assets are attached.
Context
workflow job completed webhook payload
release published webhook payload