GitLab and BuildBot

Wed Feb 8 09:04:50 UTC 2023

On 2023-02-07 23:37, Chris Johns wrote:
> On 7/2/2023 9:31 pm, Christian MAUDERER wrote:
>> On 2023-02-07 07:03, Chris Johns wrote:
>>> On 30/1/2023 10:12 pm, Christian MAUDERER wrote:
>>>> Hello,
>>>>
>>>> recently the following tickets were added (beneath a few more related ones):
>>>>
>>>> https://devel.rtems.org/ticket/4790 - Setup Gitlab instance
>>>> https://devel.rtems.org/ticket/4791 - Update BuildBot
>>>>
>>>> It's great that a patch review system and a CI/CD that builds every patch for
>>>> RTEMS starts to get within reach. Thanks a lot to all involved in that for the
>>>> efforts.
>>>
>>> It is exciting to see this happening. It will benefit the project and all who
>>> give their time.
>>>
>>>> I reviewed earlier discussions related to CI/CD. From my point of view there are
>>>> mainly two points that are missing in the tickets:
>>>>
>>>> First: From my point of view, we should make it simple for new users to
>>>> register. Adding authentication using well-known services can help with that.
>>>> GitLab supports (for example):
>>>>     - GitHub: https://docs.gitlab.com/ee/integration/github.html
>>>>     - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html
>>>>     - Google: https://docs.gitlab.com/ee/integration/google.html
>>>>     - ...
>>>> I think it would be good to select the most common ones (at least the three
>>>> mentioned above) and add them as a goal to the ticket or a new one. What do you
>>>> think?
>>>
>>> I suggest a ticket to handle authentication. If you create a ticket please
>>> indicate it is unfunded. If this is handled else where and in another ticket
>>> this one can be closed with a suitable reason.
>>>
>>
>> https://devel.rtems.org/ticket/4840
> 
> Thanks.
> 
>>> The addition of these authentication methods can be done when someone funds the
>>> work. If a person or organisation thinks it is important please reach out to
>>> Amar directly.
>>>
>>>> Second: It's still a bit unclear for me how the CI/CD with BuildBot will work.
>>>> Will it be possible for anyone to help improve the CI/CD? An example to make it
>>>> clear what I want to know: Let's assume an unprivileged developer has a patch
>>>> set that allows building device tree files using the RTEMS build system, but the
>>>> patches require a new tool like dtc. Let's further assume that the idea has been
>>>> discussed and everyone agrees that it is a good idea (currently not yet the case
>>>> for dtc). Problem is: The patches trigger a CI error because the new tool is
>>>> missing and therefore can't be merged yet. How can the developer suggest a fix
>>>> so that the patches can be accepted faster without having to wait for one
>>>> specific maintainer to have enough time for adapting the CI config?
>>>
>>> There are details that will need to be worked out. Deployment of tools for
>>> building in a CI flow is important. How complex and automated this will be will
>>> depends on the funding provided. At this point in time the push is to get a
>>> basic framework up that allows us to handle simple merge requests. The approach
>>> is more organic in nature so funding can be targeted at the most important
>>> foundation pieces. Further funding can build on that base. Before we get to
>>> Gitlab and CI we need to rebase the servers and software on them. This part of
>>> the effort is funded and under way. Amar is updating the tickets with the
>>> progress.
>>
>> Maybe my question hasn't been clear enough. Of course part of it depends on what
>> is implemented. But every selected system also adds limitations. At the moment
>> BuildBot is the suggested system in the tickets. It is a well known service and
>> has a lot of usefull features for us that certainly make it a good choice.
>>
>> But I never really worked with it, so I basically wanted to know what I have to
>> expect. Some systems like (I think it was) jenkins.io can be configured to
>> behave quite different depending on how you use it. You can either configure it
>> via a static configuration that is put somewhere where only admins can access
>> it. But you can also configure it in a way that build jobs are defined by yaml
>> files in the repository similar to popular services like GitHub, GitLab or Travis.
>>
>> Basically what I wanted to know is: What is possible / usual with BuildBot and
>> which of the possible solutions do we want to use?
> 
> A developer with a gitlab account will be encouraged to move their personal repo
> to their gitlab account and doing that allows them to use the gitlab CI tools.
> Gitlab will be running on FreeBSD and in a jail so any dependent services a
> developer needs will need to be requested via a ticket. I hope you appreciate
> there are limit here related to resources and the hardened nature of the
> environment.
> 

Of course there are limits. That's OK.

>> Do we configure BuildBot
>> statically and every change will be done only if someone pays for it?
> 
> The main CI build flows will be controlled and changed via a ticket. We need to
> QA control that process to ensure the patches merged are suitable. I have no
> idea yet how this will look and work but it will need to allow the project to
> make updates. Wether this is widely available on the first pass or pass ten of
> the work that needs to be done I cannot say.
> 

Of course every process should be checked before it is executed on our 
runners. My concern is that everyone should be able to suggest such 
changes in the form of patches (or similar) to the build scripts.

The worst case (from my point of view) would be if I have to write a 
ticket "please add new tool x to the toolchain" into a ticket and only 
one person can add it. In this case the one person will be a bottleneck 
and new features can only be added as soon as that person has time.

The best case would be "I added tool x to the toolchain. Here is a patch 
that I tested on a local instance. Please review and merge it." We still 
have a bottleneck because only few people can merge it. But at least 
it's less work for them.

>> Will there
>> be a repo with config files where everyone can suggest and help but only one or
>> two admins can accept changes if they have time? Or will every repo contain a
>> config yaml (or similar format) and every maintainer can accept a change to
>> that? Or is the currently discussed solution something completely different?
> 
> Your personal repo will have the standard gitlab features. I am not sure what
> they are. A merge request to a project repo that changes the gitlab CI config
> will need to be approved. It should be treated like any other part of the
> process. I also do not know how the project CI configs will operate in a
> personal repo. That is another issue to work out.

I think that's nearly what I described as best case above: I can create 
a merge request for the CI config even if I maybe can't test it before 
the merge request.

> 
>> That shouldn't be a pure decision by the one who pays for the work but one that
>> is (in the optimal case) discussed and specified in the tickets.
> 
> I did not know that was happening. I am sorry if you think it is and if I gave
> you that impression.

There have been relatively new tickets that changed the status from 
"needs-funding" to "funded" nearly without delay. That was a bit 
surprising for me.

It seems that the tickets are still updated based on feedback so that is 
fine and it's great that someone funded them. It just would have been 
nice if there would have been some announcement for two or three days 
like "Someone wants to fund the tickets 1, 2 and that part of 4 exactly 
like they are written now. If there are big objections with the 
direction, please speak up now."

> 
>> That way
>> everyone in the community has at least a chance to have some influence on the
>> system that he will have to use later.
> 
> That is fair. Every attempt is being made to involve the community. The tickets
> are detailed and open. Anyone can fund the work. I will point out the funding is
> not via a foundation and so it can be directed. It is not ideal but this is the
> best solution I can find so far.

Of course, it's OK that funding is directed to the tickets that someone 
wants to have funded. It's like most RTEMS development works at the 
moment and I wouldn't make that different. Like I said above: Would just 
have been nice to announce it a bit more clearly which parts of which 
tickets are funded and give a short period to object in case one of the 
tickets has a direction that is not wanted by some community members.

At the moment I don't need all tickets from my point of view. But there 
are no tickets that I would see as a problem. So again: I'm happy that 
our system will get better.

Best regards

Christian

> 
> Chris

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.mauderer at embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/