Open mkindahl opened 1 year ago
Actually I am working on this, only for private use by now. This is because in the end I will need the influx listener for armhf. Unfortunately it is crashing on startup (on amd64) by now.
If you want a Github release workflow that builds Debian packages for each release take a look at https://github.com/volkszaehler/libsml/blob/master/.github/workflows/debuild.yml .
Building a debian package for for each pull request seems a bit too much, depending on how many distributions and architectures you want to support.
I copied the current state of my packaging (not ""just works" usable) to https://github.com/narc-Ontakac2/pg_influx so it becomes visible to you. Note that you need to run
pg_buildext updatecontrol
to create debian/control.
Building a debian package for for each pull request seems a bit too much, depending on how many distributions and architectures you want to support.
My thinking was that if the packages are build and attached as artifacts to each pull request it is easy to test a pull request if necessary. Actually building the package is not very expensive, so it would be an easy way to ensure that the solution can be tested widely.
This is because in the end I will need the influx listener for armhf. Unfortunately it is crashing on startup (on amd64) by now.
Sorry about that. Issue #14 was a mistake by me that could cause a crash when using worker_launch
. Is that the same problem?
If building the package is expensive depends. If you want to build a clean Debian package you need to use pbuilder. Otherwise you will build an Ubuntu package since the system you build on is an Ubuntu. Running pbuilder has two steps. You first create a Debian base system. This is used in the second step to run the package build.
The advantages of using pbuilder are that
@narc-Ontakac2 Added Debian build information so that I can at least build a package using debuild
, but will investigate pbuilder
next.
Ensure that we build Debian packages for releases.
Tasks