On Dienstag, 21. Dezember 2021, 21:07:25 CET Marcus Schäfer wrote:
Hi Adrian,
Yes, really yet another obs git integration, but it might be the last one...
might be ;) Thanks for sharing the information. You asked for feedback and I'd like to take the opportunity to share how I use git+obs so far and also have a few questions with regards to the information you provided.
The way I connect git+obs with some of my projects is as follows:
1. The Project in obs is setup in a way that it only contains a _service file. obs should only be used to build.
2. The _service file makes use of one ore more source services mostly obs_scm. These source services connects to the git which contains data.
* For some projects I wrote my own source service because it was required to process the data in git prior obs can actually consume it. Of course to make these source service effectice, access to the obs backend is needed to install it there, such that 'osc service remoterun' becomes happy. Obviously this limits the scope to my own private instance of obs and to the places were collaboration between R&D and infrastructure happens to drive projects forward.
3. A change in git must trigger the service. I do this with help from github actions and a TOKEN (osc token) which is stored as a secret variable. For my particular projects this works nicely. Also the improved github workflow run for forked projects improved the security aspects of github secret variables. I'm sure there are voices against this concept but as I said for my particular use cases it did the job well.
This is how I combine git with obs today. Regarding your information and especially because you said you plan to make incompatible changes my first and foremost question is:
* Is the above workflow in danger regarding your upcoming changes ?
no, only the new bridge mode may receive incompatible changes. We won't touch existing workflows.
Second you asked for feedback and I guss you are aiming for use cases.
The biggest pain point in the integration as I use it so far is the fact that an obs service still commits static data at the time of the service invocation into the obs storage backend. This means some sort of update mechanism to update the data stored in the obs backend with the data on the git side is required. I explained my way of doing this in step 3) above.
yes, but the "static data" is a must have for reproducible builds, which is our highest goal.
An interesting aspect for me would be if it would be possible to just eliminate step 3) completely. Other applications e.g codacy or gitlab use Webhooks to implement the communication between services. From the information provided here I still have the feeling that this is not supported, but I might be wrong ?
hm, you write you use already github actions sending a token to trigger the updates. But you can also use the webhooks as described here: https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.source_serv... Btw, this works also with new scm bridge. In case of an entire project update the package "_project" must get triggered.
Other than that I'm happy with the options obs offers to integrate with git. I would only change my concepts if it simplifies the current procedure. From the given examples I have the feeling it would not simplify it, e.g the magic bits in .spec ... what if there is no .spec ?
yeah, there were always attempts to autogenerate spec (or any other build
description) files since the beginning of source services.
Unfortunatly we never reached a universal approach here (and no one is
working on it atm).
have a happy new year! (my last working day today)
adrian
--
Adrian Schroeter