31–40 of 100 posts
> Our CI process was pretty standard: Every commit in an MR triggered a GitLab Pipeline, which consisted of several jobs.
me: nodding silently
> Those jobs would run in an auto-scaling Kubernetes cluster with up to 21 nodes
me: what the actual deuce?
Is this really "pretty standard"?
Earlier quoted context omitted.
Docker on Debian 11 bare metal with gitlab-ci installed the "blessed" way (by adding gitlabs apt repos). No optimisation to the baseOS other than mounting the /var/lib/docker on a RAID0 array with noatime on the volume and CPU mitigations disabled on the host Compilation is mostly go binaries (with the normal stuff like go vet/go test). Rarely it will do other things like commit-lint (javascript) or KICS/SNYK scannin…
Where do you keep your bare metal machines if I my ask? I wanted to do a similar setup a while ago (building/testing on Hetzner bare metal, deployments and the rest on AWS) but due to Amazon's pricing policy the cost of traffic would be enormous.
We deploy to AWS (among others) and had no issues regarding traffic price since it's ingress into AWS.
I have a somewhat related question. I'm using gitlab-ci with it's docker executor, and overall I'm very happy with it. I use it on some rather beefy machines, but most of the CI time is not spent compiling, it is spent instead on setting up the environment. Are there any tips/tricks to speed up this startup time? I know stuff like ensuring that artifacts are not passed in if not needed can help a lot, but it seems th…
If you're mostly just compiling Go then why not cut out docker entirely? Just run your CI on bare metal.
Am I a curmudgeon? Not to take away from this cool writeup, but I'm familiar with a few CI/CD tools, particularly QuickBuild, Jenkins and Spinnaker. So this jumped out at me: > Our CI process was pretty standard: Every commit in an MR triggered a GitLab Pipeline, which consisted of several jobs. me: nodding silently > Those jobs would run in an auto-scaling Kubernetes cluster with up to 21 nodes me: what the actual d…
IMO it’s the optimal use case for K8s
I have a somewhat related question. I'm using gitlab-ci with it's docker executor, and overall I'm very happy with it. I use it on some rather beefy machines, but most of the CI time is not spent compiling, it is spent instead on setting up the environment. Are there any tips/tricks to speed up this startup time? I know stuff like ensuring that artifacts are not passed in if not needed can help a lot, but it seems th…
I'm not sure how to speed up the spin-up-a-container time (at least not without more details), but I have two suggestions that may help mitigate it. Based on your wording ("waiting for docker to spin up a container"), the second one may not be relevant. ## 1. Do more in the job's script If you have multiple jobs that use (or could use) the same image, perhaps those jobs can be combined. It's definitely a tradeoff, an…
This is a good idea and something I will seriously consider
I'm already doing #2, but I'm glad to see others come to the same conclusion as me. :D
I have a somewhat related question. I'm using gitlab-ci with it's docker executor, and overall I'm very happy with it. I use it on some rather beefy machines, but most of the CI time is not spent compiling, it is spent instead on setting up the environment. Are there any tips/tricks to speed up this startup time? I know stuff like ensuring that artifacts are not passed in if not needed can help a lot, but it seems th…
The short answer is "do as little as possible". What this means in practice is breaking down every step of CI, figuring out the dependencies for that step, and then ordering the graph of dependencies such that you start as much as possible as early as possible. This process also usually shows you where things are slow and what the critical path is. Unfortunately, doing this in most CI services is actually quite diffi…
Am I a curmudgeon? Not to take away from this cool writeup, but I'm familiar with a few CI/CD tools, particularly QuickBuild, Jenkins and Spinnaker. So this jumped out at me: > Our CI process was pretty standard: Every commit in an MR triggered a GitLab Pipeline, which consisted of several jobs. me: nodding silently > Those jobs would run in an auto-scaling Kubernetes cluster with up to 21 nodes me: what the actual d…
I have started tinkering with Fastbuild, and preliminary testing makes it seem like to good to be true, or the best thing since sliced bread. I'm sure there are drawbacks somewhere, but it's really fast.
Then again, a big chunk of our pipelines is not actually the compilation, but stuff like downloading nuget packages, uploading artifacts and stuff, all of which are. very. very. slow.
Earlier quoted context omitted.
CI is a prerequisite for CD.
It’s literally not.
Given that it's meaningless to Deploy something without Integrating the changes, what do you _actually_ mean by "You don’t need [CI]. Stick with CD only."
Are you just talking about testing the changes? Help us out here.
“In the grand scheme of things, one week isn’t that long. But to us, it felt like forever. We are constantly iterating and release multiple changes every day”.
I assume they mean multiple production releases? Is this because the product lacks maturity or stability, or is it just your culture?
I am asking because I am trying to imagine the impact of this on existing customers. It sounds like an awful lot of churn.
This obviously happens a lot in the “you are the product” space like Facebook, Google, etc. But this looks to be a data analytics product with paid tiers. Curious what tooling and processes you have to support this, and how you keep customers happy with this model.
CI has been such a productivity killer. You don’t need it. Stick with CD only and you can ship.