ci(release): publish only from tag pushes, fix Usage and Deployments in release notes

[re-gius]

Description

Fixes the release-pipeline problems hit while publishing v1.0.0.

Dispatch runs could not publish. The release tags ruleset lets only the dotns team create v* tags. A workflow_dispatch run built and tested everything, created the draft, and then failed at "Publish release": publishing a draft is the moment GitHub creates its tag, and the workflow token is not allowed to (Cannot create ref due to creations being restricted).

Both publish workflows now run only on a tag push:

• workflow_dispatch is removed from publish-release.yml and publish-prerelease.yml.
• "Resolve release tag" reads the tag that started the run. The dispatch-only guard against an existing tag, and its token, are gone.
• The concurrency group keys on github.ref_name, which is now always the tag.

Release body fixes

• The Usage snippet imported Store.json, which no release ships. It now imports LabelStore.json (both workflows).
• The Deployments section implied the listed networks run the release being published. It now says a network can still run an earlier release until it is upgraded, and points to how to tell: the protocol registry's protocolVersion()

Docs are also fixed accordingly.

Type

• Bug fix
• Feature
• Breaking change
• Documentation
• Chore
• Refactor
• Security

Scope

• Registration
• Resolver
• Store
• Proof of Personhood
• Deployment scripts
• Tests

Related Issues

Fixes

Issues during the v1.0.0 release process.

Checklist

Code

• Follows project style
• forge build passes
• forge test passes
• No new compiler warnings

Testing

• New tests added for changed behavior
• Fuzz tests added where applicable
• Invariant tests verified

Security

• No new selfdestruct or delegatecall
• Access control reviewed
• No storage layout conflicts (for upgradeable contracts)

Documentation

• NatSpec updated on changed interfaces
• README updated if needed

Breaking Changes

• No breaking changes
• Breaking changes documented below

Breaking changes:

How to test

You could test it by triggering a new pre-release.

Notes

• Repo setting to update after merge: the releases environment still allows master as a deployment ref, which only the dispatch path used. Remove it so the environment matches RELEASE_ARTIFACTS.
• The v1.0.0 release notes were corrected by hand for the same two body issues; this PR stops later releases from repeating them.

[github-actions]

CI Summary

Check	Result
File Validation	Passed - All tracked files valid
Deploy Contracts	Reproduces the expected address set; resume verified
PR Title	PR Title Valid
Labels	Unknown
Secret Scan	Passed - No secrets detected

---

Deploy Contracts

Deployed addresses vs the expected set

Expected is the committed expected-address set; actual is this CI deployment of the same pipeline.

Contract	Expected	Actual	Match
Create3Factory	0x8533c79E058c5a6489CAFeCA86dc600E029D75f5	0x8533c79E058c5a6489CAFeCA86dc600E029D75f5	match
DotnsContentResolver	0x7F74D7CD50f5a834270E2ad395a01b01891AB37d	0x7F74D7CD50f5a834270E2ad395a01b01891AB37d	match
DotnsCostModelRegistry	0x8bfd1f0957e73716732e725802f13830B5682da4	0x8bfd1f0957e73716732e725802f13830B5682da4	match
DotnsFlatPricing	0xD839B281dF72Df44fF275305E72cAEEc0fDAA648	0xD839B281dF72Df44fF275305E72cAEEc0fDAA648	match
DotnsNameEscrow	0x4881Afb78e7C908cAe818168B926229D93376520	0x4881Afb78e7C908cAe818168B926229D93376520	match
DotnsNameWhitelist	0x420166cD67Ca0233094E492a4BbA67045eD7C38C	0x420166cD67Ca0233094E492a4BbA67045eD7C38C	match
DotnsPopController	0xCC932348606cc1f3318cADeC5A5Cd2CA447f8a4b	0xCC932348606cc1f3318cADeC5A5Cd2CA447f8a4b	match
DotnsPopLens	0xfe5A45f7fD58D1A6FE09455DB799405b1dcE9411	0xfe5A45f7fD58D1A6FE09455DB799405b1dcE9411	match
DotnsPopResolver	0xDaC984884EcA8Fc44011f1D6C49B27828390A72B	0xDaC984884EcA8Fc44011f1D6C49B27828390A72B	match
DotnsProtocolRegistry	0xD19e3D0C97CF501125a04A97405e3e6592fa846E	0xD19e3D0C97CF501125a04A97405e3e6592fa846E	match
DotnsRegistrar	0x4f06E818Ba3d987704fd91cf3d868E4b019106Ab	0x4f06E818Ba3d987704fd91cf3d868E4b019106Ab	match
DotnsRegistrarController	0xBdaA01bD1bA67d709F2b1fF286Da0d854977EA30	0xBdaA01bD1bA67d709F2b1fF286Da0d854977EA30	match
DotnsRegistry	0xf34054fd76BbF85f216cf9908226D5f0A72E50CA	0xf34054fd76BbF85f216cf9908226D5f0A72E50CA	match
DotnsResolver	0xbd1165E549DF96F083c0A16f61590927bC187009	0xbd1165E549DF96F083c0A16f61590927bC187009	match
DotnsReverseResolver	0xee3883d7eB60Ee9BCD7F3bcD8f2f05302A9Cc035	0xee3883d7eB60Ee9BCD7F3bcD8f2f05302A9Cc035	match
LabelStoreBeacon	0x2227d9807F5A71332Aaa0640643030f2A3bf84cD	0x2227d9807F5A71332Aaa0640643030f2A3bf84cD	match
Multicall3	0xB4468000abD87D3c56cbFBd153161223D7b109e5	0xB4468000abD87D3c56cbFBd153161223D7b109e5	match
PopRules	0x747B456bE03aec0b42bd85C51513730FBD45DA31	0x747B456bE03aec0b42bd85C51513730FBD45DA31	match
StoreFactory	0x99605a926FcB40aB520F659c6505E5ff862771f6	0x99605a926FcB40aB520F659c6505E5ff862771f6	match
UserStoreBeacon	0x3d1Ca165f7A5e387C2df02DB2FadD3149c1C72ad	0x3d1Ca165f7A5e387C2df02DB2FadD3149c1C72ad	match

View full logs

Labels

other, type: docs

[GHkrishna]

Looks good overall, a few things:

• The releases environment still lists master as an allowed deployment branch in Settings, so the "tags only" line in RELEASE_ARTIFACTS.md isn't true yet. Can we remove it when this merges?
• The tag ruleset also blocks deleting or moving v* tags. So a re-run only helps when the failure wasn't in our code. If it needs a code fix, we have to cut a new version. Worth a line in the README.
• protocolVersion() returns the version without the v, and an empty string on networks deployed before declarations existed. A small note in the release body would save someone a confusing --tag failure.

[GHkrishna]

We should also delete the leftover draft from the failed run before tagging that version again?

[GHkrishna]

Nit: target_commitish does nothing now that the tag always exists. Fine to leave or drop?

[re-gius]

Dropped in b1c56ab

[re-gius]

Looks good overall, a few things:

* The releases environment still lists master as an allowed deployment branch in Settings, so the "tags only" line in RELEASE_ARTIFACTS.md isn't true yet. Can we remove it when this merges?

Yes, I'll remove master from the environment's deployment refs. I also added a guard job to both publish workflows: it refuses a tag whose commit is not on master, before the run asks for approval, so that we don't publish releases from untrusted commits.

* The tag ruleset also blocks deleting or moving v* tags. So a re-run only helps when the failure wasn't in our code. If it needs a code fix, we have to cut a new version. Worth a line in the README.

Added to the README's failed-run paragraph in b1c56ab

* protocolVersion() returns the version without the v, and an empty string on networks deployed before declarations existed. A small note in the release body would save someone a confusing --tag failure.

Added to the release body in b1c56ab : bare semver (1.0.0), or an empty string when the network never declared one.

[GHkrishna]

LGTM