Release action: opt in to publishing on register (DUPLOAI-3746)

[amaechiabuah]

Ticket: DUPLOAI-3746. Follows #27.

Registered versions stay unpublished by default. This adds two ways to opt in to publishing on register:

• Per extension: "publish": true on the extension's entry in .github/extension-publishers.json. A push to main publishes only a build that run newly registers, so a push resuming an existing tag never publishes and a deliberate unpublish sticks. The job reads the extension repository's own copy of the allowlist, so the flag is gated by that repository's branch protection, as the docs now say.
• Per run: a publish input on the manually dispatched Extension Release workflow. A manual run also publishes a version an earlier run already registered.

Either way, publish_build sends PATCH …/versions/{uuid}/ with is_published: true only after the build is uploaded and its artifact is registered and matches the release, and leaves an already published version alone. The console key's existing Manage extension versions capability covers publishing.

It also carries one docs commit that missed #27, naming _publish.sh, _publishers.sh and the signer's extension-sign.requirements.txt among the files the two-approval rule covers.

Test plan: every tests/test-*.sh passes and actionlint is clean. New tests cover publishing a fresh build after its artifact registers, a re-run on an already published version (no PATCH), a manual run publishing an already registered version, a push not republishing a version after it is unpublished, a push resume not publishing, a failed publish failing the job, both opt-ins in release-extensions.sh, the default staying unpublished, and the allowlist's publish field being a boolean.

[aboutte]

Two blocking concerns before this merges. Both are about when a version gets published, not how. The mechanics in maybe_publish look right.

1. With "publish": true, the next push to main republishes an unpublished version

Every push to main resumes the existing tag for each extension's current version. In release-extensions.sh, the refs/tags/$tag branch calls publish_build. The artifact already matches, so it goes straight to maybe_publish, which GETs the version, sees is_published: false, and PATCHes it to true.

So if a platform owner unpublishes a version on purpose, for example to pull a bad 1.2.0, the next unrelated merge to that repo (a README change is enough) publishes it again to every entitled install. Nothing in the log flags it. A manual run with publish checked does the same. That is the "a manual run also publishes a version an earlier run already registered" behavior in the description.

maybe_publish can't tell a version that isn't published yet from one that was deliberately unpublished. Some options:

• Publish only a version this run newly registered, never one reached through the resume or "already uploaded and registered" path.
• Or never publish from a push resume, and limit re-publishing to the manual input.
• Or, if the console records an explicit unpublish, respect it and skip the PATCH.

Whichever you pick, a test would help: a registered version gets unpublished, then a push run with "publish": true must not PATCH it.

2. The publish flag isn't reviewed in devkit at run time

The docs say:

The flag sits in devkit's reviewed allowlist, not in the extension repository, so turning it on takes the same review as joining the allowlist.

At run time, though, the workflow runs in the extension repo. _publishers.sh reads .github/extension-publishers.json from that repo's own checkout, which is the copy init-project.sh seeded. Nothing compares it with devkit's copy.

That's acceptable for the existing fields, because the AWS role's trust policy in ai-release backs them. A repo that adds itself locally is still refused by AWS. publish has nothing behind it:

• AWS doesn't know about it.
• The ai-release sync test doesn't compare it.
• CONSOLE_API_KEY already holds Manage extension versions, which covers publishing.

In practice, anyone who can merge to an extension repo's main can set "publish": true in their copy and ship every later release straight to customers, without any devkit review.

To be fair, this isn't a new hole. The same person could already edit _publish.sh to send the PATCH, because the key allows it. But this PR removes the "a platform owner publishes once the build has been verified" step and justifies that with a review gate that doesn't hold at run time. Either:

• Correct the docs: the real gate for publishing is the extension repo's branch protection plus whoever holds a key with publish rights.
• Or enforce it: for example, give the release job a console key without publish rights and publish from something devkit or ai-release controls, or have ai-release's check (or a run-time check) compare publish against devkit's pinned allowlist.

[amaechiabuah]

Both fair. A push will only publish a version that run newly registered, so an unpublish sticks, and the manual input can still republish on purpose. I'll add your test. For the second, I'll correct the docs, since the console has no key that can register without publishing.

[duplodavid]

One important item and a few small ones. A version a platform owner unpublished can go back out on the first push after the host's SDK changes. All easy to resolve.

[duplodavid]

In docs/releasing-extensions.md, the paragraph that opens "A build that is already finished" still says a matching artifact is reported as already published, which now reads as is_published. Can you change it to already uploaded and registered, to match the log line?

[amaechiabuah]

In docs/releasing-extensions.md, the paragraph that opens "A build that is already finished" still says a matching artifact is reported as already published

Changed in 88760d8.

[duplodavid]

LGTM. All five earlier items landed. Thanks @amaechiabuah!