Alias request for snap 'google-cloud-cli-arm'

store-requests
1

The ‘google-cloud-cli-arm’ snap includes five executables:

  • bq
  • gcloud
  • gsutil
  • anthoscli
  • docker-credential-gcloud

Requesting aliases for these executables. This ‘google-cloud-cli-arm’ snap is –classic snap.

Background: Since Snapcraft currently doesn’t support multiple Arch SNAP package, this google-cloud-cli-arm snap is created for ARM platform only. This is –classic snap and similar to existing google-cloud-cli snap package so it requires to have the same set of aliases.

Previous alias request for google-cloud-cli and google-cloud-sdk snaps:

2

Wondering if there’s any update on this request? Please feel free to let me know if any additional info are needed. Thanks.

3

The snap store does support per-arch snaps - so I don’t understand the need for a separate snap for arm - can you please clarify why you feel a separate snap is needed?

4

The existing SNAP package [google-cloud-cli] only supports amd64 and our goal is to add support for ARM64 as well.

We were looking at this [https://snapcraft.io/docs/architectures] document but wasn’t sure how we could build our existing SNAP package to support both amd64 and arm64 in one build.

Our google-cloud-cli snap package contains many native binaries. The binaries are introduced into the snap build process via the dump plugin. We couldn’t find a way to add both amd64 and arm64 versions of those binaries into one SNAP package.

That’s why we decided to make the snap package into a separate one to hold the arm64 separately. If you have any example snacraft.yaml file that works for both amd64 and arm64 using dump plugin, please let me know. Thank you.

5

The cleanest solution, presuming you have both AMD64 and ARM64 systems, is to build the snap on both systems producing two separate snap files, one containing AMD64 binaries, the other containing ARM64 binaries. The store will automatically deliver the correct file to the client as appropriate. Both architectures will have the same name in the store.

To make your snapcraft.yaml work with this, you likely want something similar to:

parts:
  google-cloud-cli:
    plugin: dump
    source:
     - on amd64: amd64-source
     - on arm64: arm64-source

Whilst it’s not impossible to have snaps that work across architectures with one single build, it’s primarily intended for content-snaps that would have no architecture-specific quirks (e.g, dictionary files, themes, etc).

6

For a more complete example take a look at the terraform snap: https://github.com/jnsgruk/terraform/blob/main/snap/snapcraft.yaml

7

If we build two separate snap files, one for AMD64 and one or ARM64, how do we publish them?

two different push commands?

/snap/bin/snapcraft push [ARM64_file] 
/snap/bin/snapcraft push [AMD64_file]

or would it be one snapcraft push with two files?

8

Yes, you publish each snap individually with two separate push/upload commands, as in your first example. The rest should appear to work by magic, but works because the individual snap files will have metadata that defines which platforms they’re valid for; which by default matches the host they were built on.

9

Thank you! We are able to publish the ARM package manually.

I have a few questions regarding to automate the process:

  • What happen if we keep two separate snapcraft.yaml for arm64 and amd64 to generate separate packages for the same SNAP name? Will it cause any issue with SNAP distributing packages on devices?
  • Currently, I use multipass to generate ARM snap package and it requires to set passpharse to make it work. eg…, sudo multipass set local.passphrase . Is there away to make this automate it in shell script?
  • We are wondering about snapcraft remote-build option as well. Does it need to have github account? Can auth flow be automated?

Thanks!

10

It should be fine in general to have 2 snapcraft.yaml with one for each architecture.

Regarding multipass and snapcraft remote-build - perhaps @sergiusens may be able to provide more answers in that regard.