Automaticaly connect interfaces with side loaded snaps

store
1

Hey, to have faster testing cycle(pushining, releasing and creating new image), we want to side load snaps when making images, but this has a drawback of auto connection of interfaces, since its sideloaded on a dangerous model.

To auto connect interfaces, i have tried to use gadget.yaml in gadget snap, to define interface connections as follows,

connections:
  - plug: BcWteZWyPEtK8Nc68AZ5XWcjOpmZfWoU:alsa
    slot: system:alsa

  - plug: BcWteZWyPEtK8Nc68AZ5XWcjOpmZfWoU:home
    slot: system:home

  - plug: BcWteZWyPEtK8Nc68AZ5XWcjOpmZfWoU:hardware-observe
    slot: system:hardware-observe

and created a dangerous image with side loading pulse-server snap, but its interfaces didnt connected automatically.

aliihsancengiz@6913654b-b4fb-46b2-be16-8b60487fed8a:~$ snap connections salto-pulse-server
Interface         Plug                                 Slot                               Notes
alsa              salto-pulse-server:alsa              -                                  -
audio-playback    salto-pulse-server:playback          salto-pulse-server:audio-playback  -
audio-playback    salto-ssi-outdoor:audio-playback     salto-pulse-server:audio-playback  -
audio-record      salto-pulse-server:record            -                                  -
audio-record      salto-ssi-outdoor:audio-record       salto-pulse-server:audio-record    -
bluez             salto-pulse-server:bluez             -                                  -
content           -                                    salto-pulse-server:config          -
hardware-observe  salto-pulse-server:hardware-observe  -                                  -
home              salto-pulse-server:home              -                                  -
network           salto-pulse-server:network           :network                           -
network-bind      salto-pulse-server:network-bind      :network-bind

I was wondering if there is way to achive this, which will improve our testing cycle?

Thanks in advance.

2

I would like to add that the ability to test snaps with their “normal” behavior without having to push them to the store would be critical in a secure environment for one very important reason: We want developers to be able to test snaps without having permissions to push/release to store.

3

@ogra tagging you because for some reason this question is not showing up on the Forum mainpage?

4

Because it was not assigned to a category and anything in “Other” is simply hidden from the main page…

FWIW I don’t think it is possible to have any autoconnections without having a valid assertion from the store…

I.e. you will need to upload the snaps first and use snap download to get .snap and .assert files … and these need to sit next together when pulling them into the image with ubuntu-image…

5

I see, this is pretty cumbersome for development :smiley: Are we the only ones complaining about this?

The only solution we can think of now for not creating a mess in our store is to create an extra store for development, and on “release”, re-push and re-release snaps to the production stores.

(i.e. we would have packages my-app and my-app-debug in our store, and my-app-debug has our developers as collaborators, once my-app-debug is verified, we build my-app with the same code and push and release that to the production store (this will be done by CI through PRs etc.))

What are your thoughts on this?

6

Why are channels and tracks not good enough for this ?

The requirement for uploading is simply tied to having a valid gpg signature and snap ID … You should also consider using proper store declarations instead of the gadget.yaml…

8

Hi ! @aliihsan.

I think you fully achieve this goal by installing your snaps in a “non-traditional way”, via a script (bash/zsh). :face_with_monocle:

In this way, you could for example install a snap and along the way disconnect the desired interfaces and then connect them (interfaces) manually. :thinking:

9

Can we allow users to release to channel debug/edge and not to latest/edge?

I assumed a collaborator could automatically publish to all channels

10

The thing is that we rely already a lot on interfaces on hooks like “prepare-device”, “install” and “configure”. If interfaces are not auto-connected, our code simply doesn’t work.

Of course we can work around this, but that degrades the elegance of how these snap interfaces work imho.

11

Also, we do have our interfaces in the store declarations, but they also don’t work with sideloading/dangerously installing.

Besides not allowing developers to release whatever they want to latest/stable, I would also like to just quickly tryout things in snaps without having to push 100 binaries to the store because it just seems wasteful/messy…

12

As long as you have the downloaded .snap and .assert files sitting in the same directory when pointing ubuntu-image to it they should work exactly the same as when pulled directly from the store, no matter If your model is dangerous or signed, there should not be any difference in behavior regarding declarations…

You should be able to block uploads based on reviews, so a normal uploader can upload but not release, and only a person with reviewer role will then be able to let it go to a stable channel… please open a store ticket for this if you can not find further documentation…

1 Like
13

Ok, I will try to achieve this flow of anyone pushing but only reviewer account publishing :slight_smile:

14

@Charlee, if it is written with rigor, elegance will potentially result :slightly_smiling_face: .

@ogra solution seems optimal.

15

This does not seem to work.

I have an account charlee-collaborator that:

  1. only has Viewer rights
  2. was invited to a snap by the Brand Store as collaborator

It can:

  1. push snaps
  2. release snaps

Here is the output of whoami:

email: $MY_EMAIL
username: charlee-collaborator
id: $MY_ID
permissions: package_access, package_manage, package_metrics, package_push, package_register, package_release, package_update
channels: no restrictions
expires: 2025-08-15T15:14:00.000Z

Interestingly, I also see the channels: no restrictions part that might be interesting…

I will make a support ticket with the Brand Store people for this.

Charlee

1 Like
16

I made a support ticket about this and indeed the Brand Store support guys needed to change some setting to require reviews before being able to release a snap.

1 Like
17

@aliihsan tested whether we could sideload snaps with a downloaded .snap and .assert file: the result is that it only works when the snap is in fact released… Bringing us back to the original problem; how do we test snaps including their autoconnecting interfaces without releasing snaps.

I realize this is currently probably not possible in the way we want it… But I think finding a solution for this would greatly improve efficiency of developing snaps…

18

Well, as I suggested you should use a specific track and channel… And indeed set this channel in the model assertion… Does that not work ?

You will indeed have to release it to somewhere (else you won’t get a valid assertion) but this could be a track called test/edge or some such

19

I think that, to remedy this without adding an additional layer of complexity, we would just have to add a new dev or test type publication channel like there are others like stable, candidate, beta, edge. :face_with_monocle:

However, @Charlee you can use edge for your tests. :thinking:

20

Yes true, we can use channels, and we could create a dev-channel per developer to not bother each other. However, ideally I would only be able to release to charlee/edge and not to latest/edge :smiley:

I already asked Brand Store support if this is possible but so far no reply, I’ll update once I hear something

1 Like
21

This thread heavily involves tracks and channels, but I’m curious whether branch would also work here?

A branch is a temporary release that doesn’t appear in the end-user facing UI, and can only be accessed should you know its name. A branch that doesn’t have a new revision released in 30 days is automatically closed, and any clients following it will move back to the normal releases.

E.G you should be able to, without asking for store approval, do:

snapcraft upload my.snap --release=latest/stable/james-testing-branch

This testing branch will then be signed the same way as any other upload should it pass review, at which point you can either snap download the snap and assertion to sideload it, or (potentially) link to it directly in your model.

This way multiple developers can push to their own temporary working environment, get feature parity with full uploads, but not require opening tracks nor step on each others toes.

3 Likes