Added keg obs service

[schaefi]

The fetch_from_keg obs service can be used to integrate the creation of image descriptions via keg with the open build service. This commit creates the basic structure for the service.

[schaefi]

keg & the build service

[schaefi]

_service example

<services>
    <service name="fetch_from_keg">
        <param name="git-recipes">https://github.com/SUSE-Enceladus/keg-recipes.git</param>
        <param name="branch">develop</param>
        <param name="image-source">leap/jeos/15.2</param>
    </service>
</services>

[schaefi]

Please note this is a start, the implementation to fill the service with live needs to follow based on the review of the code so far. If you test the service in this state it will just print the arguments for keg. Thanks

[rjschwei]

I like fetch_from_keg as it implies there is a pint in my near future ;) . That said, I think compose_kiwi_description would be more explanatory to those that are not familiar with keg. LGTM generally

[schaefi]

I like fetch_from_keg as it implies there is a pint in my near future ;) . That said, I think compose_kiwi_description would be more explanatory to those that are not familiar with keg. LGTM generally

Ohh really, we have such nice names for our projects and now we start to make them boring but explanatory :-)) Nah just kidding. I'm fine with a rename if the head architect @jgleissner agrees with it too

[jgleissner]

Looks good, and I really like fetch_from_keg too, but I agree that a more descriptive service name might be better.

One thing to bear in mind perhaps, we'll need support for multiple repositories since we also have a private repo, and we'll need to be able to handle a deploy token for it, that we may not want to store in _service file.

[schaefi]

@rjschwei @jgleissner I have done the rename of the service and also included the opportunity to add an additional recipe root. This results in the following service descriptions:

1. The most simple one

   <services>
       <service name="compose_kiwi_description">
           <param name="main-git-recipes">https://github.com/SUSE-Enceladus/keg-recipes.git</param>
           <param name="image-source">leap/jeos/15.2</param>
       </service>
   </services>

2. A more complex one

   <services>
       <service name="compose_kiwi_description">
           <param name="main-git-recipes">https://github.com/SUSE-Enceladus/keg-recipes.git</param>
           <param name="main-branch">develop</param>
           <param name="add-on-git-recipes">https://gitlab...super...secret</param>
           <param name="add-on-branch">develop</param>
           <param name="image-source">leap/jeos/15.2</param>
       </service>
   </services>

Notes:

• For branch names default values applies if not set. Default branch name is 'released'
• I decided to only allow for one additional recipe root. First because the obs service schema is not flexible enough to allow lists of the same parameters, second because I think it's super confusing to overlay more than one recipe root. If we ever have the case that we want to overlay recipe roots from more than two keg image definition trees we should question ourselves why this should be a good idea. For the separation of public vs. private data this makes complete sense to me, but there shouldn't be more needed.

Thoughts about this ?

Thanks

[jgleissner]

LGTM. For our use case, one additional data path should be sufficient, and I guess it will also be for other potential users.

[schaefi]

I'm currently testing this state in a real package and also stumbled of the issue in the Makefile. Thanks @jgleissner

[schaefi]

I found out that the source service automatically adds something like --outdir /home/ms/Project/sbs/external/home:sax2/test-keg-service/tmp5nc4627w.compose_kiwi_description.service to the service command call. This means the program called has to understand this option

[schaefi]

I also setup a package build using the service:

• https://build.opensuse.org/package/show/home:sax2/test-keg-service

As you can see it does not work because on the remote OBS end our service does not exist. This is expected but we have to have in mind when we are done we have to ask the OBS team to install our service

[schaefi]

ok, good to go now

[schaefi]

For testing only

osc service localrun

can be used, for the reason that I explained in the last comment. With the current state this prints the parameters passed to the service. Next step is to fill this with live :)