511–520 of 584 posts
Already see people saying GitLab is better: yes it is, but it also sucks in different ways. After years of dealing with this (first Jenkins, then GitLab, then GitHub), my takeaway is: * Write as much CI logic as possible in your own code. Does not really matter what you use (shell scripts, make, just, doit, mage, whatever) as long as it is proper, maintainable code. * Invest time that your pipelines can run locally o…
Genuine question: what's the GitLab equivalent of GitHub Actions? I'm using GitHub Actions to easily reuse some predefined job setup (like installing a certain Python version on Linux, macOS, Windows runners). For these tyoe of tasks, I find GitHub actions very useful and convenient. If you want to reuse predefined jobs, written by someone else, with GitLab CI/CD, what can I use?
There is a gitlab CI feature `include`, but you pretty much have to write shell scripts inside YAML, losing on whole developer experience (shellcheck etc..). I would recommend this way only if you can't factor your code into a CLI in proper language.
Earlier quoted context omitted.
For reusing pieces of existing pipelines I think `include` would be appropriate, especially `remote` variant: https://docs.gitlab.com/ci/yaml/#includeremote
include:component is usually what you want now, you can version your components (Semver), add a nice readme and it is somewhat integrated in the gitlab UI. Not sure about the other include: ones, but you can also define inputs for component and use them at arbitrary places like template variables. Since the integration is done statically, it means gitlab can provide you a view of the pipeline script _after_ all compo…
Is there a decent setup that one can run on their own server(s) instead? Because I'd much rather have a dedicated server sitting in a closet connected to fiber whose only job it is to be a CI runner.
GitHub Actions is just a way to build a remote single point of failure into your pipeline. I don't get why people do this. If GitHub goes down, or has problems for whatever reasons it can interfere with your deliverables to customers. I learned early in my career not to trust 3rd parties as any part of any mission critical process. 3rd parties will always fail you, it's just a matter of time.
With widespread dependencies like AWS or Github, if they go down.. you benefit from everybody else also going down. Downtime of that kind means a lot of media coverage and an easier/more understanding conversation with your affected customers. The worst kind of downtime is when you go down but nobody else has.
I don't get the obsession with YAML and making things declarative that really should not be declarative. I'm so much happier on projects where I can use the non-declarative Jenkins pipelines instead of GH Actions or BB pipelines. These YAML pipelines are bad enough on their own, but throw in a department that is gatekeeping them and use runners as powerful as my Raspberry Pi and you have a situation where a lot of de…
Earlier quoted context omitted.
Once, a reliable and wise colleague told me "Use in CI what you use locally" and that has been the best devop advice that never failed me to save my time. The second one has been, from someone else: if you can use anything else than bash, do that.
Try brainfuck... Jokes aside... it's so trendy to bash bash that it's not funny anymore. Bash is still quite reliable for work that usually gets done in CI, and nearly maintenance free if used well.
Earlier quoted context omitted.
..."gaol"?
It's the British spelling of "jail", as in "John Bunyan, a prominent Puritan preacher and author, spent 12 years in Bedford Gaol from 1660 to 1672." Pronounced jail, I believe.
Earlier quoted context omitted.
Q: How do you determine what date it was 180 days ago? A: Easy! You just spin up a Kubernetes pod with Alpine image, map a couple of files inside, run a bash script of "date" with some parameters, redirect output to a mapped file, and then read the resulting file. That's all. Here's a YAML for you. Configuration, baby! (based on actual events)
At first I assumed you were kidding, then I realised that sadly… you probably weren’t.