OneDev only cares about its own agent packaging to keep things simple.

Understandable, but the code as it stands is very fragile.

OneDev agent has a fixed layout for its distribution files, and user is not assumed to change this layout. With this assumption, the folder detection should be quite reliable.

I'm not disagreeing with that, but as a Linux distribution maintainer I would really appreciate better support for proper system packages.

I really like OneDev and I believe it deserves to make its way into more distributions' repositories. Gitea for example is available in several: https://pkgs.org/search/?q=gitea

It's not a problem for me to maintain patches in our package repository, but if they get upstreamed it's better for everyone including the project itself.

Thanks for helping to create custom distribution packages for OneDev. However both OneDev server and agent upgrade takes a quite different approach which does not play well with ordinary linux package upgrade process. Also as you've discovered, OneDev relies on propertiery software (JSW) for some of its operations (auto restart agent upon upgrade etc).

Several years ago, there are other users trying to package OneDev server as a linux package (OD-1041), and it turns out to be very difficult and finally abandoned.

However both OneDev server and agent upgrade takes a quite different approach which does not play well with ordinary linux package upgrade process.

So far I didn't encounter any issues with the server, for the agent I simply disabled the autoupdate logic: https://github.com/OpenMandrivaAssociation/onedev-agent/blob/8d4bdd3ac4a9b3a16b4e30664b283f3488d7be6d/disable-autoupdate.patch

OneDev relies on propertiery software (JSW) for some of its operations (auto restart agent upon upgrade etc).

Actually, in OpenMandriva we packaged the open-source version of Tanuki Wrapper and we're using it for both server and agent: https://github.com/OpenMandrivaAssociation/tanuki-wrapper

Several years ago, there are other users trying to package OneDev server as a linux package (OD-1041), and it turns out to be very difficult and finally abandoned.

It took some effort, but wasn't that bad honestly. We are not adhering to the common directory practices (e.g. configs in /etc/<name>), but what matters the most is permissions hardening and that's achieved.

On that note, I would be really happy if you merge https://code.onedev.io/onedev/commons/~pulls/2 because it's what allows to run unprivileged/isolated/namespaced Docker containers.

As for this pull request and https://code.onedev.io/onedev/agent/~pulls/1, I will modify the package so that they're not required anymore.

Thank you very much!

Thanks for all your effort with this. I did not know about that previously. PR addressing permissions in commons project has been merged. Also merged changes you submitted for agent project as they are not big changes.

Actually, in OpenMandriva we packaged the open-source version of Tanuki Wrapper and we're using it for both server and agent

It is great that you are replacing JSW with its OS version. I actually thought about doing that, but the lack of Windows 64 support is an obstacle.

It took some effort, but wasn't that bad honestly

The biggest trouble is for server upgrade. Currently OneDev upgrade works in the way that:

1. Download new version and extract to a folder
2. From the folder with new version, run bin/upgrade.sh /path/to/old/installation

Essentially the upgrade process needs both old version and new version in place. Old version dumps data from database, and new version upgrades data outside of database, and imports upgraded data into database. This makes the data migration really flexible (not rely on sql scripts which is quite limited), but creates upgrade difficulty when package OneDev server as ordinary unix/linux packages. The guy tried to package OneDev for Arch linux struggled for this without much success.

You're welcome!

It is great that you are replacing JSW with its OS version. I actually thought about doing that, but the lack of Windows 64 support is an obstacle.

I noticed they're only releasing x86_64 Windows binaries for the commercial version... which is unfortunate.

The community source code should build just fine for 64 bit though, I'm willing to give that a try if I find the time.

Essentially the upgrade process needs both old version and new version in place. Old version dumps data from database, and new version upgrades data outside of database, and imports upgraded data into database. This makes the data migration really flexible (not rely on sql scripts which is quite limited), but creates upgrade difficulty when package OneDev server as ordinary unix/linux packages. The guy tried to package OneDev for Arch linux struggled for this without much success.

Oh, this is the only part I'm missing, but it's feasible. I'll implement it when releasing the very first update for the package.