When we experimenting CI integration of snap lifecycle (build/publish/release), we figured out that , if you try to push a snap that requires a manual review, snapcraft push will fail, although it will upload the snap to the store and require a manual review. This is a bit confusing, because after approving it, you cannot push the same binary again to the store.
Example cases: snap publish CI job fails, which release job is dependent to that one, and when you approve snap, you cannot run snap-publish again, which is blocking release job, and pushing us to release it manually.
Is there any reason why this validation is on snapcraft publish instead of snapcraft release?
A single snap revision might be released multiple times (e.g. once to latest/edge, then later on to latest/stable). By triggering the review process on push, the revision only needs to be reviewed once and there is nothing special about the first time the revision is released.
The problem we are facing is that the exit code of the “push” command suggests a fail, and that the revision is not printed in this case.
Our release job is:
triggered if the push was successful
uses the printed revision number of the push job to decide what revision to release
In the case of apps requiring manual review this pipeline is broken.
How would you suggest automating this process?
Note: we don’t mind waiting between push and release to do the manual step in between, we even don’t mind retriggering the release job in case the push still required a manual review (in which case I guess the release will fail), but the problem is that the revision is not printed, and so our depending release job does not know what revision to release.
Example of failing push:
Status: will need manual review
Issues while processing snap:
- human review required due to 'allow-installation' constraint (bool)
I just disagree with that “failure” status, as the push actually succeeded, we pushed a binary to the store…
Can we do a feature request to at least print the revision? The exit status we can work around I guess.
You won’t be able to publish a revision that hasn’t passed review, so it’d seem your pipeline would still be broken even if the it had the revision.
Looking at the Store API docs, it would in theory be possible to return errors and a revision:
Ah yes, list-revisions should work. Because we have our git commit sha’s as version, we can search if there is any revisions with that sha and release that revision.
It does feel like a hacky work around, but I guess this is what we will be doing
Perhaps it would be possible to assign a specific non zero exit code to Snapcraft for this case (upload worked, review failed) that you could use … I’d still file a feature request…
Personally I think if the --release parameter isn’t passed, then the purpose of push is to upload the snap, not to actually have it usable, otherwise the defaults would be focused around –release being mandatory.
(For the unfamiliar, you can e.g snapcraft upload my.snap --release=latest/stable)
IMO then, assuming the server does actually recieve the snap, what it decides to do with it at that point is irrelevant, except when you’re specifically asking for it to be promoted.
(I.E, if I’ve uploaded a snap knowing it’s going to go to review, and the reviewers have asked me to, because they need to see it to review it, this isn’t a fault whatsoever. It’s also not uncommon).
The exit status we can work around I guess.
