Component
Other
Priority
P0
What happened?
Three of the last six releases published zero ABI assets: v0.5.4 (latest), v0.5.1, v0.5.0
The cause is publication order. publish-release.yml triggers on tag push and uses softprops/action-gh-release@v2 to create the release and attach assets. When the release for that tag has already been published, GitHub rejects the upload because it only allows asset uploads before a release is published.
Step-level breakdown of the v0.5.4 run (27035169120): steps 1-11 all succeed — contracts build, tests pass, Extract ABIs, Package release artifacts and Generate release body complete. Only step 12, Create release with artifacts, fails.
publish-prerelease.yml has the same shape and the same exposure: tag-push trigger, softprops/action-gh-release@v2, draft: true at :142-149.
Expected behavior
A release either carries its complete ABI set or it does not exist as a published release. Assets are attached while the release is still a draft, and publication happens only after they land. A failed release workflow blocks the release rather than leaving a published, empty one.
Separately, dotns-sdk should not build against ABIs of unknown provenance when the assets are missing.
Reproduction
# latest release carries no assets
gh api repos/paritytech/dotns/releases/latest --jq '[.assets[].name] | length'
# 0
# the two before it did
gh api repos/paritytech/dotns/releases/tags/v0.5.3 --jq '[.assets[].name] | length'
# 33
and the failing run names the reason
gh run view --repo paritytech/dotns 27035169120 --log | grep "immutable release"
To reproduce from scratch: create a release through the GitHub UI for a new vX.Y.Z tag, which publishes it immediately. The tag push triggers publish-release.yml, which builds every ABI successfully and then fails on upload.
Additional context
This blocks #118, which extends the same artifact with deployments.json so downstream projects can stop hardcoding addresses. Its entire value is that the artifact can be trusted, and an artifact that silently ships empty half the time cannot be, whatever is added to it.
#221 is the downstream consequence of consumers not being able to rely on it: the CLI hardcodes addresses in packages/cli/src/utils/constants.ts, and they went stale after the Paseo V2 reset. Suggested order is this issue, then #118, then #221 fixed by consuming the published deployments rather than re-editing the literals.
Component
Other
Priority
P0
What happened?
Three of the last six releases published zero ABI assets: v0.5.4 (latest), v0.5.1, v0.5.0
The cause is publication order.
publish-release.ymltriggers on tag push and usessoftprops/action-gh-release@v2to create the release and attach assets. When the release for that tag has already been published, GitHub rejects the upload because it only allows asset uploads before a release is published.Step-level breakdown of the v0.5.4 run (27035169120): steps 1-11 all succeed — contracts build, tests pass,
Extract ABIs,Package release artifactsandGenerate release bodycomplete. Only step 12,Create release with artifacts, fails.publish-prerelease.ymlhas the same shape and the same exposure: tag-push trigger,softprops/action-gh-release@v2,draft: trueat:142-149.Expected behavior
A release either carries its complete ABI set or it does not exist as a published release. Assets are attached while the release is still a draft, and publication happens only after they land. A failed release workflow blocks the release rather than leaving a published, empty one.
Separately,
dotns-sdkshould not build against ABIs of unknown provenance when the assets are missing.Reproduction
and the failing run names the reason
To reproduce from scratch: create a release through the GitHub UI for a new
vX.Y.Ztag, which publishes it immediately. The tag push triggerspublish-release.yml, which builds every ABI successfully and then fails on upload.Additional context
This blocks #118, which extends the same artifact with deployments.json so downstream projects can stop hardcoding addresses. Its entire value is that the artifact can be trusted, and an artifact that silently ships empty half the time cannot be, whatever is added to it.
#221 is the downstream consequence of consumers not being able to rely on it: the CLI hardcodes addresses in packages/cli/src/utils/constants.ts, and they went stale after the Paseo V2 reset. Suggested order is this issue, then #118, then #221 fixed by consuming the published deployments rather than re-editing the literals.