We are going to deploy our snaps to Snapcraft automatically, but firstly we need a staging server for QA purposes. The main problem is that the QA team builds and publishes and tests the build several times before this particular version will be officially released. It means that we must be able to upload packages that may somehow conflict with the previously uploaded versions during this process.
Usually we host and use our own server, and completely remove all uploaded packages before each iteration.
Are there any alternative SNAP store (api/v2) implementations that conform snapcraft.io, and that we can use internally?
Is there some kind of API to remove or ignore conflicts with previously uploaded packages (we will register a special private snap name for it).
If not, I think we can create such “a special private snap name” uniqually for each iteration. But it means there can be up to tens or even hundreds of private snaps for each official release. Is it possible?
Of course, we will be ready to unregister & remove them after some time, but AFAIK it cannot be done automatically (without filing a public request).
You could make your QA team be collaborators on the Snap package in the public Store. When you upload to the Store you can “not release” the revision(s) so that the general public cannot install it. Make a note internally of which revision relates to which QA requirement and then your QA team ensure they are logged-into snapd with:
sudo snap login user@example.com
And then they can install an unreleased revision with:
snap install $snapname --revision=123
user@example.com is their individual Launchpad/Ubuntu SSO ID.
Hi! I think we need more information before we can suggest something.
Can you detail how a package may conflict? I’m unclear in that aspect.
We have plenty of snaps that do per-commit builds, each of those results in an individual revision, which can be published and tested separately. One thing you could do is publish each build to a branch. You can create branches yourself so this can be easily automated. Branches are non-discoverable (meaning if you don’t know a priori the name of the branch, it won’t show in snap info) and they expire after 30 days, so builds will be unpublished after that time.
However, the actual snap builds/revisions themselves are not / cannot be removed. But that’s not a problem, just ignore them
Not at this time.
In principle yes, as noted above.
I need more information about conflicts here.
While possible, I would recommend against it, it will be awkward for you and for us to wrangle snap names and they are not easily revokable/removable. They will be with you for a long time.
While a possibility, we usually advise against this because collaborators also have full upload/publishing privileges to the snap. If you want to trust your QA team with this authority, then perhaps - but it might be inadvisable or undesirable per your process.
Sharing a snap login/password widely also increases the attack surface of systems where a compromise could lead to a malicious snap build being uploaded.
That’s a good thought. I’m now wondering if we can get the store to provide a role that allows for installation of unreleased/private snaps without allowing upload rights. Sort of a privileged but read-only access?
Oh it’s been discussed and requested in the past, but we don’t have anything like that at the moment and it would need a bit of design/thought. We’ll certainly publicize it once we have something more concrete.
Channels exist precisely to cover use cases such as this, and typically you would just have your CI process building and releasing to the “edge” channel, which you can then install from for further testing before promoting that revision to the other risk channels (edge -> beta -> candidate -> stable).
As @roadmr notes, branch channels allow for more sophisticated release scenarios but I would suggest you start by just having your test builds released to the edge channel.
Hi again. Sorry for a long delay, wanted to give it a try.
Yes, we did it this way.
Our CI process can be run several times on the same packages, so we faced with binary_sha3_384: A file with this exact same content has already been uploaded error, but I found how to get a sha3-384 of uploaded revisions (api/v2), so we just handled it the right way, and now everything looks workable.
BTW, how do you use your staging server? Is it intended to use for regular users who publishes .snap files (like me), or it’s just for internal use by snapcraft devs?
