[JohnMcLear]

The publish-stable job uploaded the same .snap a second time, which the store rejects ("binary_sha3_384: Error checking upload uniqueness"). It now runs snapcraft promote etherpad --from-channel latest/edge --to-channel latest/stable, so stable gets exactly the revision that was tested on edge. The snap-store-stable environment approval gate is unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TcYAoDMav4BPPE9JrMtSvw

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Promote the published edge snap revision to stable

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Replace the duplicate stable upload, which the Snap Store rejects, with an edge-to-stable
 promotion.
• Keep stable publication behind the existing GitHub Environment approval gate.

Diagram

graph TD
  B["Build snap"] --> P["Publish edge"] --> E[("Edge revision")] --> A["Approval gate"] --> M["Snapcraft promote"] --> S[("Stable channel")]

Loading

High-Level Assessment

Promoting the edge revision is the appropriate approach: it preserves the existing approval gate and avoids the rejected duplicate upload. Releasing by an extracted revision number would add bookkeeping without a clear benefit here.

Files changed (1) +7 / -9

Bug fix (1) +7 / -9

snap-publish.ymlPromote edge to stable instead of uploading twice +7/-9

Promote edge to stable instead of uploading twice

• The stable job installs Snapcraft and promotes etherpad from latest/edge to latest/stable using the store credential. It no longer downloads the build artifact or publishes the same binary a second time; its environment approval gate remains in place.

.github/workflows/snap-publish.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

1. Old approvals can release the wrong tag 🐞 Bug ≡ Correctness

Description

publish-stable promotes the current contents of latest/edge rather than a revision tied to its
own publish-edge job. If another tagged run publishes to edge while this run waits for environment
approval, approving the older run releases the other tag's revision to stable without that tag's
approval.

Code

.github/workflows/snap-publish.yml[90]

+        run: snapcraft promote etherpad --from-channel latest/edge --to-channel latest/stable --yes

Evidence

The workflow accepts multiple tag pushes and defines no concurrency constraint. The edge job
releases each run's artifact to the shared edge channel; the stable job waits behind an environment
approval but its new command selects by channel name, not by the artifact or Store revision from its
own run.

.github/workflows/snap-publish.yml[20-28]
.github/workflows/snap-publish.yml[52-70]
.github/workflows/snap-publish.yml[72-90]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The stable job reads a mutable edge channel after an approval delay, so another tagged run can replace the revision it promotes.

## Fix Focus Areas
- .github/workflows/snap-publish.yml[52-70]
- .github/workflows/snap-publish.yml[72-90]

## Recommended Fix
Capture the Store revision published to edge by this run and pass it as a job output to `publish-stable`. After approval, release that explicit revision to stable instead of resolving `latest/edge` at promotion time. Ensure overlapping tagged runs cannot misassociate a revision with an artifact while capturing it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: Auto: ⚖️ Balanced: Changes the stable release publish path using store credentials; a single hunk.

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗