InodeLabs/fern
1
14
Fork
You've already forked fern
2

snap: add snapcraft packaging #12

Merged
bugwhisperer merged 1 commit from zyga/fern:feature/snapcraft into main 2026年04月17日 14:41:16 +02:00
Contributor
Copy link

This adds basic snap packaging using core24 as base, a few typical plugs
and some tweaks to the organize and build phases to embed the right
version information into the binary and the snap meta-data.

Once this is merged you can set up an automatic build pipeline
on launchpad where a daily version is built and pushed the store.
You must separately register the fern name in the store and set
up the build configuration as a one-off step. I can help with that
if necessary.

Thank you for making fern, I find it very useful.

Signed-off-by: Zygmunt Krynicki me@zygoon.pl

This adds basic snap packaging using core24 as base, a few typical plugs and some tweaks to the organize and build phases to embed the right version information into the binary and the snap meta-data. Once this is merged you can set up an automatic build pipeline on launchpad where a daily version is built and pushed the store. You must separately register the fern name in the store and set up the build configuration as a one-off step. I can help with that if necessary. Thank you for making fern, I find it very useful. Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>
snap: add snapcraft packaging
All checks were successful
ci/woodpecker/pr/ci Pipeline was successful
7ba36f128f 
This adds basic snap packaging using core24 as base, a few typical plugs
and some tweaks to the organize and build phases to embed the right
version information into the binary and the snap meta-data.
Signed-off-by: Zygmunt Krynicki <me@zygoon.pl>

Thank you so much for the kind words @zyga! I'm happy that you a finding Fern to be useful!

This Snap addition to the CI looks great from initial review. I'll work on setting up the launchpad side of things and testing the builds locally before approving and merging. Will ask here if anything comes up during testing.

Thank you so much for the kind words @zyga! I'm happy that you a finding Fern to be useful! This Snap addition to the CI looks great from initial review. I'll work on setting up the launchpad side of things and testing the builds locally before approving and merging. Will ask here if anything comes up during testing.
Author
Contributor
Copy link

@bugwhisperer wrote in #12 (comment):

Thank you so much for the kind words @zyga! I'm happy that you a finding Fern to be useful!

This Snap addition to the CI looks great from initial review. I'll work on setting up the launchpad side of things and testing the builds locally before approving and merging. Will ask here if anything comes up during testing.

Thanks

From usability point of view, the main question is if the snap should prefer to store data in the $SNAP_USER_COMMON location or in home. The fact that config file remembers the location of the vault is relevant, because data stored in $SNAP_USER_DATA ~/snap/fern/$revision will change location on every refresh (update) of the snap.

Personally I stored the vault in ~/snap/fern/common/vault as I think that is the right balance of usability right now, but I don't want to speak for everyone.

@bugwhisperer wrote in https://codeberg.org/InodeLabs/fern/pulls/12#issuecomment-13254318: > Thank you so much for the kind words @zyga! I'm happy that you a finding Fern to be useful! > > This Snap addition to the CI looks great from initial review. I'll work on setting up the launchpad side of things and testing the builds locally before approving and merging. Will ask here if anything comes up during testing. Thanks From usability point of view, the main question is if the snap should prefer to store data in the $SNAP_USER_COMMON location or in home. The fact that config file remembers the location of the vault is relevant, because data stored in $SNAP_USER_DATA ~/snap/fern/$revision will change location on every refresh (update) of the snap. Personally I stored the vault in ~/snap/fern/common/vault as I think that is the right balance of usability right now, but I don't want to speak for everyone.
@ -0,0 +43,4 @@
override-pull:|
craftctl default
# Set defaults
grade=devel
Author
Contributor
Copy link

Grade devel prevents publishing releases to the stable channel. If the release is exactly from a tag, then grade is set to stable and such build can be published into any channel.

Grade devel prevents publishing releases to the stable channel. If the release is exactly from a tag, then grade is set to stable and such build can be published into any channel.

Cool! If I'm following everything correctly, that would allow us to setup separate channel recipes like: stable vs edge?

Cool! If I'm following everything correctly, that would allow us to setup separate channel recipes like: `stable` vs `edge`?
Author
Contributor
Copy link

Yes but without the need for anything separate in git.

The snap store has for each snap, a set of tracks. By default all snaps get the "latest" track but can freely request more tracks to organize e.g. 1.x and 2.x releases that live in parallel. For each track you get four channels - stable, candidate, beta and edge.

Anyone can install the snap from any track/channel they want.

There are also branches that are at the end of that combination but let's discuss those separately.

A typical arrangement is to set up launchpad to build a given repository e.g. daily and publish the result to latest/edge. When you make a new release, the tagged git commit can be built and this would result it having a nice short version (without the git hash) and grade=stable (not devel). You can then manually publish such build to, say, beta or candidate and ask your community to test. You can also publish to stable straight away if you feel like it. The key idea there is that this is not a new build but the build that was already done earlier, just tested for a while.

You can do channel publishing from command line or from the browser (personally I usually use the browser for doing that as it is just quite a bit more intuitive).

The advantage of channels and tracks is that it allows everyone - developers and users - to move at their own pace freely.

Branches are an extra concept and allow you to create named things that are short lived (30 days). Therer are many use-cases for branches but typically for exploring hot-fixes with users or customers, for experiment and so on. The key property there is that one cannot ask for a list of branches, only the publisher knows the branch names, and that once a branch, say latest/edge/i18n-experiment expires, everyone who used to subscribe to that branch gets promoted to latest/edge so they still receive updates.

Let me know if you have any questions about this. I'll gladly help :)

Yes but without the need for anything separate in git. The snap store has for each snap, a set of tracks. By default all snaps get the "latest" track but can freely request more tracks to organize e.g. 1.x and 2.x releases that live in parallel. For each track you get four channels - stable, candidate, beta and edge. Anyone can install the snap from any track/channel they want. There are also branches that are at the end of that combination but let's discuss those separately. A typical arrangement is to set up launchpad to build a given repository e.g. daily and publish the result to latest/edge. When you make a new release, the tagged git commit can be built and this would result it having a nice short version (without the git hash) and grade=stable (not devel). You can then manually publish such build to, say, beta or candidate and ask your community to test. You can also publish to stable straight away if you feel like it. The key idea there is that this is not a new build but the build that was already done earlier, just tested for a while. You can do channel publishing from command line or from the browser (personally I usually use the browser for doing that as it is just quite a bit more intuitive). The advantage of channels and tracks is that it allows everyone - developers and users - to move at their own pace freely. Branches are an extra concept and allow you to create named things that are short lived (30 days). Therer are many use-cases for branches but typically for exploring hot-fixes with users or customers, for experiment and so on. The key property there is that one cannot ask for a list of branches, only the publisher knows the branch names, and that once a branch, say latest/edge/i18n-experiment expires, everyone who used to subscribe to that branch gets promoted to latest/edge so they still receive updates. Let me know if you have any questions about this. I'll gladly help :)

@zyga wrote in #12 (comment):

@bugwhisperer wrote in #12 (comment):

Thank you so much for the kind words @zyga! I'm happy that you a finding Fern to be useful!
This Snap addition to the CI looks great from initial review. I'll work on setting up the launchpad side of things and testing the builds locally before approving and merging. Will ask here if anything comes up during testing.

Thanks

From usability point of view, the main question is if the snap should prefer to store data in the $SNAP_USER_COMMON location or in home. The fact that config file remembers the location of the vault is relevant, because data stored in $SNAP_USER_DATA ~/snap/fern/$revision will change location on every refresh (update) of the snap.

Personally I stored the vault in ~/snap/fern/common/vault as I think that is the right balance of usability right now, but I don't want to speak for everyone.

I agree with your assessment. We can go with that for now.

@zyga wrote in https://codeberg.org/InodeLabs/fern/pulls/12#issuecomment-13254669: > @bugwhisperer wrote in #12 (comment): > > > Thank you so much for the kind words @zyga! I'm happy that you a finding Fern to be useful! > > This Snap addition to the CI looks great from initial review. I'll work on setting up the launchpad side of things and testing the builds locally before approving and merging. Will ask here if anything comes up during testing. > > Thanks > > From usability point of view, the main question is if the snap should prefer to store data in the $SNAP_USER_COMMON location or in home. The fact that config file remembers the location of the vault is relevant, because data stored in $SNAP_USER_DATA ~/snap/fern/$revision will change location on every refresh (update) of the snap. > > Personally I stored the vault in ~/snap/fern/common/vault as I think that is the right balance of usability right now, but I don't want to speak for everyone. I agree with your assessment. We can go with that for now.
Author
Contributor
Copy link

@bugwhisperer please read this https://documentation.ubuntu.com/launchpad/user/how-to/packaging/build-snaps-in-launchpad/ to add a snap build recipe to launchpad without having to host the source code there.

EDIT: posted too soon.

Once you create the recipe you can point launchpad to any Git repository by editing the recipe.

@bugwhisperer please read this https://documentation.ubuntu.com/launchpad/user/how-to/packaging/build-snaps-in-launchpad/ to add a snap build recipe to launchpad without having to host the source code there. EDIT: posted too soon. Once you create the recipe you can point launchpad to any Git repository by editing the recipe.
Sign in to join this conversation.
No reviewers
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
InodeLabs/fern!12
Reference in a new issue
InodeLabs/fern
No description provided.
Delete branch "zyga/fern:feature/snapcraft"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?