Expose docker tags for Snapcraft 2.x

It’s great to see Snapcraft 3.0 out! :slight_smile:

Firefox may need a little bit of time to migrate its build to 3.0. We wanted to pin the hash of the current stable docker image, but a limitation in our CI prevents use from pinning hashes. A second solution would be to move away from the stable tag in favor of 2, for instance.

Is there any plan to such a tag on https://store.docker.com/r/snapcore/snapcraft/tags ?

Thanks in advance!


AFAIK the old syntax is still supported if you don’t specify the base keyword, is that really necessary?

@Lin-Buo-Ren is correct, if you’re not specifying a base nothing should break for you in v3.

1 Like

We don’t seem to be specifying anything named base, but this is the original error I got, building snapcraft from the master branch as of a few weeks ago:

Issues while validating snapcraft.yaml: The 'parts/desktop-gtk3' property does not match the required schema: 'plugin' is a required property

I tried again using the 3.0.1 tag and at first got an exception which seems to be because /snap/bin wasn’t in my $PATH on the build host, so the multipass that was snap installed wasn’t found. I added that and got the 'plugin' is a required property error again.

So then I tried the 3.0 tag, which downloaded a VM image (!), and ran it, and ended up with a different exception.

I can’t link to the snapcraft.yaml because this forum limits me to two links per comment, but it’s reduced from a file named snapcraft.yaml.in in the Firefox source.

Let’s see if I can add the other links in a second comment: my snapcraft.yaml, the upstream source.

Wait, so are you not using the snapcraft docker images? Are you running from source? Indeed, that doesn’t work the way I outlined, but you can clone the legacy branch instead that will.

1 Like

Thanks all for the quick answers!

To clarify the thread, we’re now talking about 2 different things:

  1. what our automation produces, which is based on the Snapcraft docker image
  2. what Jed found when he wanted to generate a local build, thanks to his build from the snapcraft master branch

1. Automation/Docker image

Automation is using the snapcraft docker image for builds. This was the main concern of this thread. I verified if our build scripts would still run with the current beta snapcraft docker image. I confirm it worked! Thus, I don’t think we need docker tags anymore. Thank you @Lin-Buo-Ren and @kyrofa for highlighting this :slight_smile:

2. snapcraft source build

Would you all prefer if I moved the discussion under a new thread? I’d love to understand why there’s a difference between the 3.0.1 docker image and the 3.0.1 source scripts.

1 Like

No need for a new topic, this is pretty simple :slight_smile: . Actually only the snap works the way I outlined, but our docker images are based on our snap, so it inherits the magic.

When building the snap, we actually put two snapcrafts in there, the master branch, which as you’ve noticed has broken backward compatibility, and the legacy branch, which is essentially 2.x. Take a look at the snapcraft.yaml to get an idea of what I’m saying.

Then, when the snap sees a snapcraft.yaml, it checks to see if it has a base. If so, it uses the new snapcraft, the master branch. If not, it uses the old snapcraft so things don’t break. We did it this way so that we didn’t need to continue maintaining legacy APIs and features that were holding us back, while still allowing for them to be used and not break people. This allows us to maintain what are essentially two major versions of snapcraft (cherry-picking bugfixes from master to legacy) while still allowing both to be consumed as a single release.

Admittedly, that makes running from source a tad confusing, I’m sorry about that.

1 Like

Aha, I see! It makes sense to me, then. Marking this topic as resolved.

1 Like