Automated branch publishing for pull requests?

In Channels | Snapcraft documentation:


A branch is an optional finer subdivision of a channel for a published snap that allows for the creation of a short-lived sequences of snaps that can be pushed on demand by snap developers to help with fixes or temporary experimentation.

Branch names convey their purpose, such as fix-for-bug123, but the name isn’t exposed in the normal way, such as with snap info. Instead, they can be tracked by anyone simply knowing the name.

After 30 days with no further updates, a branch will be closed automatically. The replacement snap will then be chosen as it would be with closed channels (see below). For example, beta/fix-for-bug123 will fall back to beta after the fix-for-bug123 branch is closed.

I wonder whether we can use this functionality for PRs created for the Snapcrafters adopted snaps, to facilitate testing (e.g. The original issue reporter can try to reproduce the issue using the snap automatically built from the PR to a certain channel, like latest/beta/for-pr123.)

1 Like

Also for additional context I am trying to comment the following in Snap does not update PATH variable which results in unusable snap · Issue #11 · snapcrafters/gradle:

The problem is snap still points to nonexisting Java 11.

It appears that Gradle points to the Java runtime bundled in the snap itself instead of the one possibly installed in the host system. Please try

We do this on many of the Mir snaps using a github workflow. For example:

(This does require setting up a token to enable upload to the store.)

1 Like