Full integration of snapcraft

[ghost]

Snapcraft 3.0 introduces new functionality that is currently not supported in goreleaser. It would be really useful to reflect these changes in goreleaser and allow full compatibility with snapcraft.

Example: base:core18

The base keyword specifies a special kind of snap that provides a minimal set of libraries common to most applications, and it is mounted as the root filesystem for application.

Proposed enhancement

Allow developers to import entire snapcraft.yaml into .goreleaser.yml as is, and then selectively replace specific fields, e.g. name, description using variables (to allow integration and automatic builds), but then pass other declarations to snapcraft without additional syntactic checks (in these are not explicitly supported in goreleaser).

[caarlos0]

which fields are missing? (besides base)?

[caarlos0]

If you have a documentation link it will also be helpful.

I tried looking into https://docs.snapcraft.io/snapcraft-yaml-reference/4276, but couldn't find anything related to core18 and the base and core links does not work...

Another question I have is: can I declare dependencies? For example, if I have an app that depends on git... how can I make it work?

Snapcraft.yaml reference - Documentation for snaps: Universal Linux packages

[ghost]

Hi Carlos,

So here's what I was thinking (apart from the fields you already support):

Parts

For example, this include:

parts:
appname:
plugin: go
source: https://github.com/something.git
go-importpath: github.com/something

But this could look different for other languages, like python for instance - this isn't the scope of go, but the idea is that there are keywords you might not necessarily use in a given scenario, but they could exist, and someone may try them.

parts:
appname:
plugin: python
python-version: python2
source: https://github.com/something.git

Anyway, these are two examples where you also use plugins to build, with language-specific overrides.

There could also be stage packages and build packages:

parts:
something:
plugin: go
source: https://github.com/something/something.git
go-importpath: github.com/something
build-packages:
- build-essential
- libpcap-dev
- libnetfilter-queue-dev
stage-packages:
- libpcap0.8
- libnfnetlink0
- libnetfilter-queue1

BTW, we have language guide wizards here: https://snapcraft.io/first-snap

This is the more relevant documentation:
https://docs.snapcraft.io/the-snapcraft-format/8337
https://docs.snapcraft.io/snapcraft-parts-metadata/8336
https://docs.snapcraft.io/snapcraft-app-and-service-metadata/8335

Hooks

Conditional triggers:
https://docs.snapcraft.io/supported-snap-hooks/3795

I agree that the current documentation can be improved, and I'll take your feedback as another pointer on this.

My suggestion would be - if there's a declaration that you don't support it at the moment, ignore it and pass it on to snapcraft as is, and worse case, there will be an error in snapcraft but the build won't be blocked by goreleaser.

Hopefully, this makes sense.

Thanks.

Page not found · GitHub

Snapcraft

Snapcraft - Snaps are universal Linux packages

Snaps are containerised software packages that are simple to create and install. They auto-update and are safe to run. And because they bundle their dependencies, they work on all major Linux systems without modification.

The snapcraft format - Documentation for snaps: Universal Linux packages

Snapcraft parts metadata - Documentation for snaps: Universal Linux packages

Snapcraft app and service metadata - Documentation for snaps: Universal Linux packages

Supported snap hooks - Documentation for snaps: Universal Linux packages

[guilhem]

Since snapcore/snapd#5845 is solved, we can set files permitted to be edited by software. (without having to be native confinement)

plugs:
  personal-files:
    read:
      - $HOME/.kube/config
      - $HOME/.minikube/client.key
      - $HOME/.minikube/client.crt
      - $HOME/.minikube/ca.crt

This is not in apps.plugs

aliases is also really important when your repository have multiple binaries.

Here is a complete list of yaml parameters: https://github.com/snapcore/snapd/blob/master/snap/info_snap_yaml.go#L35

GitHub

snapcore/snapd

The snapd and snap tools enable systems to work with .snap files. - snapcore/snapd

[caarlos0]

if I understand correctly, the parts thing is used to build the snap, right? If so, it doesn't make sense for goreleaser, as the binary will be already compiled...

[ghost]

You can use parts with the dump plugin - so you don't compile, you just grab the source. But then, if you compiled with different libraries than snapcraft has (in its base), you will need to specify them as stage packages.

https://docs.snapcraft.io/the-dump-plugin/8007

But if you support all parts/plugins, developers have the options to choose what they need.

Thanks!

The dump plugin - Documentation for snaps: Universal Linux packages

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jimafisk]

This feature would be really great to have! We're building a static site generator with a Go CLI that requires running npm and node to compile svelte components. Unfortunately we aren't able to execute npm/node outside of our snap: plentico/plenti#31

I was able to add home and network-bind plugs to allow writing to the filesystem and serving a local website while still using strict confinement. However, it would require classic confinement to execute the user's system npm/node, which under manual review it was suggested to use stage-packages/stage-snaps instead: https://forum.snapcraft.io/t/classic-confinement-request-for-plenti/17803/9?u=jimafisk

[caarlos0]

happy to review a PR on that. :)

FWIW there is one opened that adds some stuff #1553

[jimafisk]

Thanks and sorry if I came across as demanding. Goreleaser is amazing, I def appreciate all the hard work the team is doing :).

[caarlos0]

No problem at all, just that I don't have time to work on this right now, so if someone can work on a PR it would be awesome :)

sorry if I sounded defensive or something, was not the intent

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.