Setup Gitlab instance

[Amar Takhar]

• Setup Gitlab to handle patch submissions and CI.
• Require a build-before-merge scenario
• Connect to BuildBot to run builds

Features

• Inline patch comments
• Cyclical building during pull request updating
• Community developer accounts and RTEMS related code hosting
• Remote Gitlab instance connectors
• Can be run alongside Trac
• Opensource and self-hosted
• No lock-in we have access to all our data no issues of ownership

[Christian Mauderer]

GitLab? is a great system and I would be thrilled to see RTEMS switch to a system like that.

Just a side note: It seems that you plan to integrate GitLab? with BuildBot?. I don't have a problem with any working CI/CD system so that's OK for me. But GitLab? is a quite big system, partially because it brings it's own CI/CD system. I have read some opinions that (if the CI is not used) some more lightweight alternative like Gitea or it's new forge Forgejo can be simpler to maintain. Note that this is more a rumor that I picked up somewhere so don't take it for granted. If you say GitLab? is no problem at all or you already have experience with it, I would suggest to stick to it. It's a great system.

[Amar Takhar]

These are some good points and I'll try to answer as best I can here why GitLab over Gitea or other options.

We're not using GitLab for any of it's actual CI abilities but it's interaction abilities. For instance you can have cyclical workflows. I'll use the word 'Developer' here to also include Contributors:

1. Developer submits pull request.
2. CI interface builds RTEMS first-pass builds say, ERC32 and some tests using GDB Sim and in the future 1 real hardware test.
3. Feedback is given by GitLab on the success of these builds if it passes it goes forward if not the submitter can fix their issues and re-submit the pull request until it builds OK they can also ask for help in this process.
   • This also saves us time in ensuring we're dealing with working code most of the time the submitter can fix it themselves.
4. Once everything tests OK we can then push this for full testing before commit to the main branch if it breaks there we can go back to step #3.

The other strong addition of GitLab is the ability for inline comments to patches. Right now we use the mailing list for feedback which makes for terrible historical records. It's difficult to search, difficult to track and frankly hard to use for modern developers. Web interfaces have become ubiquitous for this kind of work and inline patch comments has been a golden egg in source control for the last two decades it's time we move to it as well.

Relying on GitLab to do our CI isn't fruitful as it really wants a commit or an instigator to trigger a build. There are many cases where an old commit has broken a platform that we only build every few days -- a tier 3 or 4 platform. We can't have these holding up merges to the main branch which is why they are on a low tier.

CI happens on more levels outside of a trigger for complex systems especially when you had multi level hardware tests, tool chain building and the ability for external contributors to let tests run on their hardware. Decoupling the builds and CI from our source control *and* development platform lets us switch any of these. Of course we don't have to stick with just Buildbot we can choose to use other testing systems with GitLab as well if they are useful enough.

With GitLab we'll be able to give out accounts to community members to house their RTEMS related code and have it build and test on our infrastructure. This helps them in their development process in quickly getting them up and running and increasing the quality of code they submit to the project. Having patches that have already built and passed tests is supreme: It saves *everyone* time.

We can also hook our build infrastructure into outside GitLab instances. If someone else is running GitLab or even Github they can hook into Buildbot to run builds using our setup.

Buildbot also allows us to easily run Builders/Workers? on remote hardware. I have plenty of hardware here I plan to setup and Chris also has hardware at his location he can setup. Buildbot allows us to very easily support this and by extension anyone using our GitLab instance can.

Gitea is very lightweight and I do run it myself here for my own code management I love it but it's too light for our purposes we'd end up shoehorning a lot of scripts and outside programs to make it work it's easier to just setup GitLab despite it being much, much heavier.

As far as Buildbot goes it's been around for a very long time and is extremely stable it just works. I haven't used the actual interface to Buildbot for a very long time but I have been using it for doing builds on hardware and software both embedded and non it will run for years without issue. In the future if we decide to switch out we can because it will still be decoupled from everything else but for now it solves a lot what we need.

I do have a lot of experience running it as well I've set it up for multiple clients it's always worked amazingly well. Thanks for the input!

[Christian Mauderer]

Thanks for the detailed explanation. Most of the first part is general CI requirements and I fully agree with these. The important part is: You evaluated and have experience with both systems and Gitea lacks functionality. That's enough to answer my comment.

I never worked with Buildbot so I'm not sure how it works or how it is configured and how easy it is for everyone to contribute to that configuration. But that would be a separate discussion that would most likely be better on the mailing list.

[Amar Takhar]

Add to project-2