Call for testing: Github action for Snapcraft

snapcraft
21

Our sprint starts first days of March

1 Like
22

I don’t sprint.

1 Like
23

Hi,

Was this work selected for your sprint in the end?

D.

24

Yes, @cjp256 is working on it, but we have other priorities to tend to at the moment.

25

Awesome, I’ll quietly await any updates when you or @cjp256 has time :smiley:

26

@cjp256 @sergiusens - I don’t want to nag, and I imagine with the current global situation certain things slipped, but is there any word on when I might be able to expect the actions to be made official?

27

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
28

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
29

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
30

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…

31

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.

32

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.

33

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
34

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

35

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
36

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

2 Likes
37

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
38

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

39

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
40

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