@postophagous thank you for wanting to get involved with this question despite being unfamiliar with GitLab.
I cannot give more context about GitLab because I am not terribly familiar with GitLab either, and I am precisely avoiding to get terribly familiar with GitLab. That's the whole point of this question: I want a set of standard, boilerplate, no-brainer, minimum required, necessary and sufficient magical incantations that must be performed on GitLab so that from that point on I do not have to care at all about the fact that I am using GitLab.
That would be:
Something like the list of conditioning steps that I listed for GitHub, which behaves fine after that.
Something like what they used to have to do in web development with normalize.css a.k.a. "CSS reset" so as to start from a blank slate which is exactly the same in all browsers and from that point build their web-site without having to worry which browser they are running on.
All I know about GitLab is that all sorts of things that work locally do not work there. For example, when I execute git branch --show-current on GitLab, I get an empty string. This probably means detached head, but I do not know for sure, and I do not care to know.
I see CI/CD providers as just tools to get a certain job done; they should be as easy as possible to use, but for various reasons (1) they are not; they require an awful lot of coercing and begging and whispering to work. Mysteriously, CI/CD folk all over the planet are willing to spend copious amounts of time learning the quirks and tricks of each CI/CD provider, with the following handicaps:
This is preposterous, and I am not willing to participate in it.
For me, things are simple: I have a build script. I run the build script locally, it builds. I now want to run this build script on the cloud. Is GitLab capable of running my script as it is? Great. Is GitLab incapable of doing that? #@*& off!
(1) various reasons: mostly aspirations of market dominance via vendor lock-in.