search

acts-project / acts-core-test

Mozilla Public License 2.0
1 stars 0 forks source link

Can/should/must we switch away from CERN Gitlab? #639

Open paulgessinger opened 4 years ago

paulgessinger commented 4 years ago

GitLab issue: #717

Arguments

Non-exhaustive list of pro/contra arguments.

For staying with CERN Gitlab

Against staying with CERN Gitlab

Requirements for another hosting solution

A non-exhaustive list of functionality that we need to host the Acts development in addition to hosting just the git repository.

paulgessinger commented 4 years ago

Original comment by: hgraslan at 2020-03-10 17:22:53

To expand a bit on the CVMFS issue, any CI service that only provides unprivileged Docker containers (e.g. GitHub Actions) is not usable here because these containers do not have enough OS permissions to mount FUSE filesystems. We need either self-hosted hardware of a VM-based CI service.

paulgessinger commented 4 years ago

Original comment by: hgraslan at 2020-03-10 17:28:15

Regarding the possibility of plugging CERN CI resources into a service like GitHub, it's technically possible, but it may prove to be politically difficult or impossible to negotiate with CERN IT.

paulgessinger commented 4 years ago

Original comment by: pagessin at 2020-03-10 17:28:50

CERN knowledge base article on when Github is "recommended": https://cern.service-now.com/service-portal/article.do?n=KB0003132. Basically: if you have external contributors: use Github.

paulgessinger commented 4 years ago

Original comment by: pagessin at 2020-03-10 17:35:39

For reference, Github features issue tracking and wikis. Also we'd be able to get visual coverage tracking like this:

Screen_Shot_2020-03-10_at_17.36.16

paulgessinger commented 4 years ago

Original comment by: hgraslan at 2020-03-10 17:39:35

Honestly, I think that CI is where most of our attention should be focused. I'm constantly switching between GitHub and Gitlab depending on the project, and all the other features that I use frequently (code browsing, issues, merge requests, wikis...) work too similarly for a clear case to be made in favor of one platform or another.

(Well, okay, GitHub's discussion thread UI is rather awful compared to that of Gitlab, but as long as we're careful never to engage in any long discussion on an MR or issue, it won't be a big problem.)

paulgessinger commented 4 years ago

Original comment by: pagessin at 2020-03-10 17:42:50

Yeah, honestly, I would refrain from making arguments on the pros and cons of Gitlab vs. Github interfaces, since ultimately, we'd be weighing our convenience against the fact that the project can't be contributed to from non-CERN people.

My personal opinion is: if the CI is workable (which I feel like it is) we should make the switch.

paulgessinger commented 4 years ago

Original comment by: hgraslan at 2020-03-10 17:52:28

...and I agree with this assessment, when it comes to the decision of switching from CERN Gitlab to a public code cloud.

Where this information can play a role, however, is that once we have proven that moving out of CERN is feasible in general, we may want to give some thought to the subsequent choice between github.com and gitlab.com.

paulgessinger commented 4 years ago

Original comment by: pagessin at 2020-03-10 18:32:29

Fair point. Concerning this: I believe Gitlab.com's shared runner will have the same problem concerning CVMFS, so we'd have to be allowed to use our private runners there as well, or use an image based on @ adye's suggestion.