Is there a reason to keep this separate from the existing integration project?

In T285913#7189159, @Legoktm wrote:

Is there a reason to keep this separate from the existing integration project?

There's no technical reason, but it feels cleaner to keep them separated. There's no technical reason they need to be in the same project, either. If it's harder to have a seperate project we can combine them, but if not let's separate them.

A separate project from the Jenkins job runners seems ok to me. Soon enough™ the Jenkins things will decomm, but until then it seems reasonable to have the extra privilege separation between the two systems of an OpenStack project boundary.

I wonder if "gitlab-runners", "gitlab-workers", or even "ci-workers" might be a more obvious explanation of the purpose of the project. I get that "integration" is derived from https://en.wikipedia.org/wiki/Continuous_integration, but it has always felt like an obfuscated project name to me.

In T285913#7191447, @bd808 wrote:

A separate project from the Jenkins job runners seems ok to me. Soon enough™ the Jenkins things will decomm, but until then it seems reasonable to have the extra privilege separation between the two systems of an OpenStack project boundary.

I wonder if "gitlab-runners", "gitlab-workers", or even "ci-workers" might be a more obvious explanation of the purpose of the project. I get that "integration" is derived from https://en.wikipedia.org/wiki/Continuous_integration, but it has always felt like an obfuscated project name to me.

I too have thought that "integration" was a confusing name. +1 for "gitlab-workers".

If we're bikeshedding the naming, I don't have strong feelings here, but "gitlab-runners" does align exactly with the name of the software we intend to run.

Mentioned in SAL (#wikimedia-cloud) [2021-07-13T14:33:47Z] <balloons> create project, initial quota 60 cores, 175G RAM T285913