Call for testing: Github action for Snapcraft

Sorry for all the delays. We made an in principle agreement to make the actions official projects, but didn’t get round to creating the new projects.

Originally the plan was to move my repos over to “snapcore”, which was difficult to handle due to permissions (I don’t have permission to create new repos there, and other people don’t have permission to move repos I personally own). We’ve now created new repos instead, which was probably a better idea all along so as not to break workflows already using the actions:

These should be compatible with the old actions other than the name.

7 Likes

I’ve published a new version of snapcore/action-build@v1 that is compatible with the Snapcraft 4.0, which was recently promoted to stable. I had been running Snapcraft under sudo, which it now complains about. I now configure things so that the CI user can launch LXD containers directly.

One other change in behaviour is that builds will now generate a snap/manifest.yaml file, as Launchpad/build.snapcraft.io do. The changes to implement this were in the previous release of the action, but it wasn’t until Snapcraft 4.0 that manifest generation worked for LXD builds. The manifest will also include the URL of the workflow run in the build_url property of the manifest.

One benefit of including the manifest is that it enables detection of published snaps that have staged Ubuntu packages with security vulnerabilities.

2 Likes

I’ve pushed out another update to snapcore/action-build@v1. The main feature of this release is compatibility with Github’s ubuntu-20.04 runner image (which is not yet aliased to ubuntu-latest).

Previously, the action assumed that if the LXD snap was installed that it was usable (e.g. because it had been set up by a previous run of the action). In the ubuntu-20.04 image, the snap is installed but lxd init has not been run, and the CI user is not a member of the lxd group. The new version of the action performs those setup steps unconditionally now.

1 Like

action-build@v1 does not work anymore for my repository since the update. I’m getting a lot of exceptions while using the catkin_tools plugin. First one:

Errors << catkin_tools_prebuild:cmake /root/parts/workspace/build/logs/catkin_tools_prebuild/build.cmake.000.log
Traceback (most recent call last):
  File "/root/parts/workspace/install/usr/lib/python3/dist-packages/lsb_release.py", line 38, in get_distro_info
    csvfile = open('/usr/share/distro-info/%s.csv' % origin.lower())
FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/distro-info/debian.csv'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/root/parts/workspace/install/usr/bin/lsb_release", line 26, in <module>
    import lsb_release
  File "/root/parts/workspace/install/usr/lib/python3/dist-packages/lsb_release.py", line 57, in <module>
    get_distro_info()
  File "/root/parts/workspace/install/usr/lib/python3/dist-packages/lsb_release.py", line 41, in get_distro_info
    csvfile = open('/usr/share/distro-info/debian.csv')
FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/distro-info/debian.csv'
CMake Error at /root/parts/workspace/install/opt/ros/melodic/share/catkin/cmake/platform/lsb.cmake:8 (string):
  string no output variable specified
Call Stack (most recent call first):
  /root/parts/workspace/install/opt/ros/melodic/share/catkin/cmake/all.cmake:164 (include)
  /root/parts/workspace/install/opt/ros/melodic/share/catkin/cmake/catkinConfig.cmake:20 (include)
  CMakeLists.txt:4 (find_package)

I’m running it on Ubuntu 18.04. I’m reading a lot of “Python 3” in this error messages, but this ROS version still uses Python 2. Not sure if this is relevant…

Does your snap build locally with current stable Snapcraft, using either Multipass or LXD? If that also fails, then the problem does not reside in the action.

There were some pretty large changes in the Snapcraft 4.0 release, so if you haven’t tried building your snap recently, it’s possible you’re hitting a bug or incompatibility with the new version.

Builds fine on my system with snapcraft 4.0.5 (only 4.0.4 had a problem with the catkin-tools). I did not change the default, therefore, I guess I’m using Multipass.

The build of the catkin-tools ROS package itself is the one which fails. And this one is loaded by the catkin-tools plugin. I’m not sure if catkin-tools is already available on Ubuntu 20.04. But since I’m using 18.04 I assume this shouldn’t be a problem.

Perhaps there is some difference between the package set in the Multipass and LXD images Snapcraft runs with?

Looking at the error message, something is running a copy of the lsb_release tool in the part’s install dir, which in turn is looking for data files in /usr/share/distro-info. These data files appear to be from the distro-info-data package, and nothing tries to install it.

@cjp256: is this something the catkin-tools plugin should automatically pull in as build-packages?

2 Likes

Seems like a good idea. It does look like the multipass image has this installed whereas the LXD counterpart does not.

We had a similar issue, I ended up changing the lxd sock permissions before building the snap and it fixed the issue.

sudo chown $USER:$USER /var/snap/lxd/common/lxd/unix.socket

Adding the distro-info-data package to the build dependencies solved it.

2 Likes

I’ve published updates to both actions, as Github’s dependabot was bugging me to update the @actions/core library version. This comes with a few new features:

  1. snapcore/action-build now has a snapcraft-channel input parameter that allows you to use something other than Snapcraft’s stable channel.
  2. snapcore/action-build now has a snapcraft-args input parameter to set additional arguments to pass to Snapcraft. This is intended to allow passing the --enable-experimental-* options to turn on experimental features.
  3. snapcore/action-publish now calls snapcraft upload rather than snapcraft push, which gets rid of a deprecation warning in the logs.
2 Likes

I wonder if this supports all architectures available in the Snap Store?

Github only provides amd64 VMs by default. If you’re able to cross compile your code, then you probably can build snaps for all architectures on the provided infrastructure (e.g. the rustup snap does this).

It is also possible to register self hosted runners to handle your workflows. So if you’ve got an S390 sitting in your closet, you could give that a shot.

2 Likes

Are there any examples for writing plug-declaration.json and slot-declaration.json?

Apologies for the necro reply.

Hello! Is this (original top post) still valid?

It’s the first hit that turns up when looking for “github actions”.

I just tried adding it to a random snap I manage, and it failed. Which makes me think either a) I need to read every single one of the 40 replies, or b) it’s outdated, or c) someone else superseded this with something else.

Googling beyond this forum lands me at the marketplace Snapcraft Action · Actions · GitHub Marketplace

Might be worth linking to this in the very top post and wipe out the prototype?

Call for testing: Github action for Snapcraft does link to the official actions. Those just haven’t been updated to the first post for some reason and can’t be easily found from the GitHub Marketplace either.

Try changing your workflow to call snapcore/action-build@v1 instead of the version in my repo. We ended up moving the action over to a repo not exclusively controlled by me.

There wasn’t a good way to redirect users of the original repo, so I didn’t delete the original.

Thanks James. That also failed. https://github.com/popey/x16emu-snap/actions/runs/6458250252/job/17531564815

I was expecting to just be able to paste a chunk in and get a snap out at the end. Is it not as simple as that?

It looks like the action itself is working fine, the build environment looks like it’s missing build-parts though.

make[1]: lzsa: No such file or directory

There’s a very few select packages that are implicit in the build for Multipass, but not LXD, Launchpad, etc. It’s possible lzsa might be something that’s default on one of these but not the rest, especially when the base snap is updated. (but in all my time here, I’ve only encountered one).

2 Likes

Oof, well spotted, thanks!