Our sprint starts first days of March
Was this work selected for your sprint in the end?
Yes, @cjp256 is working on it, but we have other priorities to tend to at the moment.
Awesome, I’ll quietly await any updates when you or @cjp256 has time
@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?
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.
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.
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
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.
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
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
distro-info-data package to the build dependencies solved it.
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:
snapcore/action-buildnow has a
snapcraft-channelinput parameter that allows you to use something other than Snapcraft’s stable channel.
snapcore/action-buildnow has a
snapcraft-argsinput parameter to set additional arguments to pass to Snapcraft. This is intended to allow passing the
--enable-experimental-*options to turn on experimental features.
snapcraft uploadrather than
snapcraft push, which gets rid of a deprecation warning in the logs.
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.