On 2022-08-17 16:03, Dany Marcoux wrote:
On 2022-08-17 15 h 32, Claudius Heine wrote:
Hi,
I am rather new to OBS and I am currently looking into ways to integrate CI with OBS. We are using a private Gitlab server that also has some CI runners. We want to build packages for Debian and Ubuntu.
The privat repo hosts the unpacked debianized project sources (directory containing the project + a `/debian` directory containing package metadata), which AFAIK aren't supported by OBS, it only supports Debian source packages (*.dsc, *.debian.tar.xz and *.orig.tar.gz, etc. files).
So the general idea would be to use the CI on Gitlab to package the source packages and then pushing those via `osc add ... && osc ci` from the CI runner to OBS and let OBS take care of managing the APT repo and building for all different archs etc.
But how would authentication work for this? I see that there is a `osc token` command, which looks good, however I am not sure how to match the operations `runservice`, `release` or `rebuild` to the required `osc ci` in order to upload the new source packages to OBS.
I guess we could just put a OSC cookiejar on the CI runner, but that seems overkill and likely against the least privilege security principle.
There is some documentation about integrating OSC with webhooks into Gitlab/Github in order to run on every merge request, but that isn't really required, since we already have CI runners for this, and I am not sure if those Webhooks even work for a private Gitlab instance, that isn't easily reachable from outside.
Any other ideas?
Thanks, Claudius Heine
Hi Claudius,
Hi Dany, thanks for your reply!
Did you have a look at the SCM/CI Workflow Integration[1]? It sounds like a good match for what you want to do. To summarize what it does, you setup your SCM repositories, set workflows (with YAML) to do what you need like branching or rebuilding packages and you get the state of the build results directly on GitLab. This way, you get quick feedback on the changes you did in your branches / merge requests. Please have a look at the documentation linked below and let me know if something isn't clear.
This is what I referred to as 'some documentation about integrating OSC with webhooks' in my initial mail. And as I also described, we just want to "let OBS take care of managing the APT repo and building for all different archs etc.". We have internal CI builders that can test build some packages and run package lints etc. on each merge request, but building for non-native platforms or managing and hosting APT repositories is simpler with OBS than the internal infrastructure.
By private GitLab server, do you mean hidden on some internal network or is it self-hosted and publicly available? As long as OBS can contact your GitLab instance, it's fine.
As I said in my mail "not sure if those Webhooks even work for a private Gitab instance, that isn't easily reachable from outside.". The private GitLab instance is hosted inside an internal network, so webhooks probably don't work.
This feature is part of the beta program[2] on OBS, but it's already used internally at SUSE. We're simply gathering more feedback before rolling it out.
As I described, it would probably be the simplest way if `osc` can just be fed a token and then is allowed to push new packages to OBS from a CI runner. That way the process would just assume that there exist some system that can execute `osc` and has outgoing http(s) access to the internet. The Webhooks approach might be more convenient, but it assumes much more about the infrastructure of the client. regards, Claudius