[RTEMS Project] #4790: Setup Gitlab instance

[RTEMS trac]

#4790: Setup Gitlab instance
------------------------------------------+-------------------------
 Reporter:  Amar Takhar                   |       Owner:  (none)
     Type:  infra                         |      Status:  new
 Priority:  normal                        |   Milestone:  Indefinite
Component:  admin                         |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  need-funding                  |  Blocked By:  4784
 Blocking:  3872, 4791, 4792, 4793, 4798  |
------------------------------------------+-------------------------

Comment (by 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.
   1. CI interface builds RTEMS first-pass builds say, ERC32 and some tests
 using GDB Sim and in the future 1 real hardware test.
   1. 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.
   1. 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!

--
Ticket URL: <http://devel.rtems.org/ticket/4790#comment:8>
RTEMS Project <http://www.rtems.org/>
RTEMS Project