4 ms·

Right, my point was that I shouldn't need to enforce this. Gitlab yaml allows and often goes out of its way to encourage non-portable practices.

orf 7y ago
But... it just runs shell commands. It doesn’t encourage you to do more complex things, especially compared to other CI systems like Jenkins. My point is your complaint seems more general than Gitlab itself.
- ipodopt 7y ago
  Well, let's see. I am going to exaggerate a touch here but here is what I see at my workplace: a. They will write an inline script. Solution: Rip it out into a file. b. Each Job is using a different container. Solution: use Docker with mapped volumes or we all have the same machines (this might not be possible for some workloads) and only use a single container. Why not run the shell directly you may ask? b.1 Each container has a different environment and my machine has one. b.2 Some things do not run natively on my machine that do on theirs. c. Variables are defined in the yaml instead of the scripts. Solution: Make a local .env file see b. So sure, a local gitlab runner us probably best patch here. But I am imagine if someone made a container runtime specifically for this then wrapped that in a CI config it could be very ergonomic. Which is what I would explore if I where to write a IC today. I am sure some build system today already does this... Things outside (kindof) of Gitlab's control that I might as well complain about while I am here: d. And regardless, there are transient dependencies everywhere (which I blame the all language creators for really, mfs :P ). So everything gets fucked eventually anyhow. Wouldn't it be nice if you could whip out a three year old project, run the build, and its exactly as you left it? e. People thinks all right to allow for mutable versions so I have to asdjnasdaskdjasdlasjdl;askjd;asldkj = asdasdljkdasl;kdjlaskdjaslkjd some non-human readable hash if I am feeling paranoid. d. and e. are firmly in the language creators hand I believe. But Gitlab does offer artifact repositories (which are non-portable and could also easily could be). Gitlab could also save dependency trees in different languages. But really I would gripe to the tool/language creators.
  - Tainnor 7y ago
    But the things that add complexity at least to our gitlab config are precisely things you can't really test well locally, like: - making sure you can access the AWS docker image registry, which may require particular runner configuration - making sure deploy keys are set up correctly so you can access private dependencies - testing caching behaviour - testing improvements to pipeline duration (for us, just parallelising and reordering some things meant build times decreasing from 24 to 9 minutes) - testing when exactly jobs should be triggered (e.g. stages, "only", "when", etc.) - testing the predefined variables (such as the name of the branch) - and so on
  - donmcronald 7y ago
    I agree with this and do the same for a, b, c. It wouldn't surprise me at all to see projects treating Docker based jobs / pipelines like they're deterministic. Unless you learn how everything interacts and are really careful it's very difficult to create repeatable builds with GitLab CI (and most other CI) because of what you say in d. If you can't run a build with your internet disconnected, it's not repeatable and you don't own it. The thing is it's MUCH better for companies like GitLab and GitHub to get you locked in to their SaaS build systems, so simple, repeatable, offline builds will never be a priority. The harder it is, the better it is because they can charge you more money to "manage" it. I have no idea how someone looks at a system like GitHub Actions and likes it. To me it seems obvious what's going on a GitHub. Eventually Microsoft is going to marry a bunch of tech together (ex: GitHub, Visual Studio Online, GitHub Actions, Azure Resource Manager) and everyone will be so hyped about how easy it is to click a button and have dev, build, deploy "just work" that they'll blindly give up control of their development and build environment. Just look at how easy it was for Apple and Google to convince developers to give up their ability to deploy apps without being blessed.

orf 7y ago

But... it just runs shell commands. It doesn’t encourage you to do more complex things, especially compared to other CI systems like Jenkins. My point is your complaint seems more general than Gitlab itself.

ipodopt 7y ago
Well, let's see. I am going to exaggerate a touch here but here is what I see at my workplace: a. They will write an inline script. Solution: Rip it out into a file. b. Each Job is using a different container. Solution: use Docker with mapped volumes or we all have the same machines (this might not be possible for some workloads) and only use a single container. Why not run the shell directly you may ask? b.1 Each container has a different environment and my machine has one. b.2 Some things do not run natively on my machine that do on theirs. c. Variables are defined in the yaml instead of the scripts. Solution: Make a local .env file see b. So sure, a local gitlab runner us probably best patch here. But I am imagine if someone made a container runtime specifically for this then wrapped that in a CI config it could be very ergonomic. Which is what I would explore if I where to write a IC today. I am sure some build system today already does this... Things outside (kindof) of Gitlab's control that I might as well complain about while I am here: d. And regardless, there are transient dependencies everywhere (which I blame the all language creators for really, mfs :P ). So everything gets fucked eventually anyhow. Wouldn't it be nice if you could whip out a three year old project, run the build, and its exactly as you left it? e. People thinks all right to allow for mutable versions so I have to asdjnasdaskdjasdlasjdl;askjd;asldkj = asdasdljkdasl;kdjlaskdjaslkjd some non-human readable hash if I am feeling paranoid. d. and e. are firmly in the language creators hand I believe. But Gitlab does offer artifact repositories (which are non-portable and could also easily could be). Gitlab could also save dependency trees in different languages. But really I would gripe to the tool/language creators.
- Tainnor 7y ago
  But the things that add complexity at least to our gitlab config are precisely things you can't really test well locally, like: - making sure you can access the AWS docker image registry, which may require particular runner configuration - making sure deploy keys are set up correctly so you can access private dependencies - testing caching behaviour - testing improvements to pipeline duration (for us, just parallelising and reordering some things meant build times decreasing from 24 to 9 minutes) - testing when exactly jobs should be triggered (e.g. stages, "only", "when", etc.) - testing the predefined variables (such as the name of the branch) - and so on
- donmcronald 7y ago
  I agree with this and do the same for a, b, c. It wouldn't surprise me at all to see projects treating Docker based jobs / pipelines like they're deterministic. Unless you learn how everything interacts and are really careful it's very difficult to create repeatable builds with GitLab CI (and most other CI) because of what you say in d. If you can't run a build with your internet disconnected, it's not repeatable and you don't own it. The thing is it's MUCH better for companies like GitLab and GitHub to get you locked in to their SaaS build systems, so simple, repeatable, offline builds will never be a priority. The harder it is, the better it is because they can charge you more money to "manage" it. I have no idea how someone looks at a system like GitHub Actions and likes it. To me it seems obvious what's going on a GitHub. Eventually Microsoft is going to marry a bunch of tech together (ex: GitHub, Visual Studio Online, GitHub Actions, Azure Resource Manager) and everyone will be so hyped about how easy it is to click a button and have dev, build, deploy "just work" that they'll blindly give up control of their development and build environment. Just look at how easy it was for Apple and Google to convince developers to give up their ability to deploy apps without being blessed.