Differentiate “need manual review” status in "snapcraft upload" from errors
Metadata
Current evaluation
Feature request to differentiate 'need manual review' exit code from errors in snapcraft upload for CI pipelines. Maintainer acknowledged with two proposed solutions (distinct exit codes via #6081, and --format json). No implementation yet.
Suggested action: keep open
Reason: Maintainer @mr-cal acknowledged the issue and proposed two concrete solutions (distinct return codes tracked in #6081, and a --format json option). The reporter confirmed the return-code approach as the priority. Issue #6081 is still open and triaged, so this remains a valid, scoped enhancement awaiting implementation.
Impact:
45
Quick Win:
24.75
Staleness:
50
Complexity:
45
Confidence:
78
Support Request:
25
Issue body
### Check existing issues
- [x] I've verified that this request isn't described by any existing issues.
### Request
The `snapcraft upload` CLI tool should return a different return value when it ends with “need manual review” status, compared to actual errors.
### The problem it solves
A problem we encountered on GIMP's release pipeline is that this "need manual review" status broke our pipeline (as it apparently didn’t return 0). As a consequence:
1. it stopped after uploading one out of the 2 archs;
2. a few other steps in the release procedure were made more annoying (because for failed pipelines, Gitlab won’t generate some “easy” redirection URLs used by our scripts to publish other binaries to our download infra).
We still want to see real failures, but “need manual review” is not actually a failure, right? We just wait a bit to get the manual validation. So I’d like for our pipeline to still pass as success in this “manual review” case, which is why I wish to be able to react conditionally on the return value.
P.S.: as initially [reported on the snapcraft forums](https://forum.snapcraft.io/t/personal-files-request-for-gimp/50315/10?u=gimp).
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
45
Quick Win:
24.75
Staleness:
50
Complexity:
45
Confidence:
78
Support Request:
25
|
keep open | Feature request to differentiate 'need manual review' exit code from errors in snapcraft upload for CI pipelines. Maintainer acknowledged with two proposed solutions (distinct exit codes via #6081, and --format json). No implementation yet. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
45
Complexity:
30
Confidence:
85
Support Request:
15
|
needs triage | Request to return a distinct exit code for manual review status in snapcraft upload to prevent CI pipeline failures. Currently inactive with no labels or assignee. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
50
Complexity:
25
Confidence:
85
Support Request:
10
|
needs triage | Request to return a distinct exit code for need manual review status in snapcraft upload to prevent CI pipeline failures. Maintainer suggested exit code changes or JSON output; author prefers exit codes first. Currently under discussion with no labels or assignee. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
45
Complexity:
20
Confidence:
85
Support Request:
10
|
keep open | Requests snapcraft upload to return a distinct exit code for manual review status instead of treating it as an error, preventing CI pipeline breaks. Under discussion; maintainers propose exit code changes or a JSON output format. Awaiting implementation. |
Update history
No update history recorded yet.
Related work
-
Related To:
snapcraft#6081
(confidence 90%)
Maintainer explicitly referenced #6081 as solution 1 for this issue; #6081 covers the broader 'return different error codes for snapcraft upload responses' enhancement.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #6081 Return different error codes for `snapcraft upload` responses | snapcraft | open | Enhancement to make `snapcraft upload` return distinct exit codes per store processing status (ready_to_release, being_processed, need_manual_review, processing errors) so CI workflows can handle results programmatically. Triaged, acknowledged by a maintainer, not yet implemented in client.py. |