Add systemd unit files to the RPM/DEB packages

[johanneskastl]

• add systemd unit file for server (woodpecker-server.service)
• add systemd unit file for agent (woodpecker-agent.service)
• add systemd unit files to nfpm package definitions
• add etc config file examples

fixes #1575

[lafriks]

For rpm/deb packages we should probably not use /usr/local but standart locations

[johanneskastl]

For rpm/deb packages we should probably not use /usr/local but standart locations

I just extended what was already there with the systemd units.

Using /usr/bin/ instead of /usr/local/bin is a different discussion. Especially as the RPM/DEB is not a full-fledged package with what most distributions expect and does not adhere to their guidelines. Basically it just packages the binary currently.

So my 2 cents would be that using /usr/local/bin is fine.

[pat-s]

I don't have much experience bundling binaries + systemd but let's try to make some progress:

• I assume you created the bundles locally and tested them?
• We should extend the docs to explain that users need/can place env vars in /etc/woodpecker/woodpecker-server.env (and the agent counterpart).

[johanneskastl]

* I assume you created the bundles locally and tested them?

I tested them manually, i.e. I spun up VMs, installed the RPMs without the systemd service and then created the files locally.

The systemd units look similar to what I packaged for openSUSE in the server and agent packages, where I have a vagrant-libvirt setup for testing:

https://github.com/johanneskastl/woodpecker_vagrant_libvirt_ansible

The major difference is that I create a system user woodpecker for the openSUSE package and use it for the woodpecker services. This is not in this PR, as creating users from RPM/DEB is not done the same way on all distros, hence hard to package in a generic RPM/DEB.

I did not have time to prepare a similar setup using the upstream packages and the files from this PR.

* We should extend the docs to explain that users need/can place env vars in `/etc/woodpecker/woodpecker-server.env` (and the agent counterpart).

I have no idea how creating RPM/DEB packages with nfpm works, but I think it might be a good idea to create the /etc/woodpecker/ directory and maybe add an example file in there, to show people how the syntax in that file should be.

[zc-devs]

creating users from RPM/DEB is not done the same way on all distros

Now, there is a way.

[johanneskastl]

creating users from RPM/DEB is not done the same way on all distros

Now, there is a way.

I know that systemd und RPM support user creation, that is how openSUSE handles this.

But the DEB and RPM packages are used on other distributions. And are built using nfpm, where I do not know how easy it is to package the files and add the necessary %pre and %post snippets.

But if someone wants to add this functionality to this PR, please feel free. I just wanted to start with a basic example that should (hopefully) work everywhere[tm].

[zc-devs]

I know that systemd und RPM support user creation, that is how openSUSE handles this.

👍

But the DEB

But the title of the issue contains only to the RPM packages.

RPM packages are used on other distributions

All of them use RPM.org-version. And here you have introduced systemd dependency, am I right?
So, the question is whether the last versions of major RPM distributions are carrying Rpm >= 4.19 🤷‍♂️

---

I also don't know about nfpm, not requesting changes and not willing to add this functionality.

I just wanted to start with a basic example

Sure. Just skip my comments :)

[johanneskastl]

But the DEB

But the title of the issue contains only to the RPM packages.

Good catch, fixed that just now, as nfpm is used to build both DEB and RPM packages.

[6543]

could we add example env files with default values so people can change them ...

[johanneskastl]

could we add example env files with default values so people can change them ...

As far as I understood it there are no default values, as it highly depends on which Forge you are connecting to.

Adding a general example file that shows the syntax would be fine, but as this is all in the documentation already it does not make that much sense to duplicate that information...

[6543]

I would still prefere it the config files would be created ... not everybody reads systemd service configs but know how to ls /etc/[service]/

Its also fine to leafe it empty or ad only a comment with a link to the docs

[johanneskastl]

I would still prefere it the config files would be created ... not everybody reads systemd service configs but know how to ls /etc/[service]/

I have added two example files (that are named *.example) with instructions.

The units will not start, unless the file with the proper name is present. This makes it clearer / easier to find out that you need to create that file with your settings.

What do you think?

[6543]

please just merge target branch into this and commit new things directly onto feature branches ...

a forcepush make it harder to review the diff from last time i reviewed ...

[6543]

thanks anyway :)

[woodpecker-bot]

Tearing down https://woodpecker-ci-woodpecker-pr-3986.surge.sh

[kastl-ars]

please just merge target branch into this and commit new things directly onto feature branches ...

a forcepush make it harder to review the diff from last time i reviewed ...

Sorry, rebasing is what most other projects want so I am used to it...

Thanks for taking care and merging.

[ibpan-biblioteka]

I'm confused, was this removed again shortly after being added? I don't see these files in the main anymore or in the .debs...

[ibpan-biblioteka]

Nvm I looked at the wrong repo's main and it seems that simply a new release wasn't made since it was merged, forget it then