CI: Build and test packages for Debian (unstable, to begin with)
This is a follow-up of a private mail:
-
With the last release, 3.2.2, I've ran into big problems because of the ruby 2.5 transition which started in Debian unstable. We've tested with ruby-arel 6.0.4, in Debian unstable 6.0.3 was available, which didn't work with ruby 2.5. I had to first update ruby-arel.
-
Therefore: I would like to spot problems which are related to packaging or cause trouble afterwards as early as possible, i.e. while developing, to not just become of them aware after the new version is already released.
-
Regarding the implementation, I've something along these lines in my head:
- A separate branch debian/unstable, which contains only debian/ and therefore all configs etc. needed to build a Debian package.
- Introducing a submodule, which references this branch.
- The CI job to build the package should checkout this submodule and use common Debian tools afterwards to try to build the package.
-
This is a "high-level" overview, but wanted to outline the idea. I expect some showstoppers to become visible while developing.
@sssggr @n_g @paz Could you comment on this? Not because you should do this, but more in regard to if you would merge something like this. (Actually the only changes to master will be contained in .gitmodules and .gitlab-ci.yml.)
--
What to do:
-
Build package -
Run lintian -
Run piuparts (this needs a chroot; think about using GitLab CI SSH runner to connect to a KVM instance with available chroot) -
Run autopkgtest (this needs ideally LXC, which I would like to make available in a VM) -
Run reprotest (makes the build fail as of 2018/07/15 even with all variations disabled; seems buggy currently)