Live data from Hacker News

Write Gitlab CI Pipelines in Python Code

gitlab.com

41–50 of 97 posts

Re: Write Gitlab CI Pipelines in Python Code

#41
post #4

What I would really like to see is a CI system that lets me write a script in a language of my choice instead of defining a pipeline config file. That way I can run the pipeline locally, put breakpoints in, etc. Nuke [1] gets close but there are still a lot of tasks that don't have C# bindings, such as publishing build artifacts and uploading test results. While I'm dreaming about my perfect CI, I'd also like the abi…

Check out tekton CI ( https://tekton.dev/ ), it's a Kubernetes operator to run a CI pipeline that's defined as commands running inside any container. Use any language, any commands, etc--as long as you can get a container image, you're good to go. There's a growing set of community created and curated actions to do common things too: https://github.com/tektoncd/catalog Yeah you need a k8s cluster, but even a simple k…

We use Tekton to manage our CI pipeline and I agree that the way it enforces very little structure is a strength. On the other hand it's new enough that if you need to stretch its capabilities you are going to have to get creative. The primitives it has are nice, but they have their limits.

For instance, if running a bunch of parallel tasks, collating results on a PV is out the window unless your cluster supports multiple writer volume types, which GKE does not. You have to bring in NFS volume types or something like that for it. In the early days of tekton they had a results primitive which synchronized an output dir to GCS, but they decommissioned that. So you are left pushing that logic into your task command. Running gsutil is easy enough, but it means you are pushing logic into your scripts and not declaring steps in the pipeline definition. You could make that command a step but I see little benefit in that.

Additionally there is no way to loop in the configuration to generate tasks, much less loop with an ordinal value. We end up just programmatically generating the resource definitions with ruby erb templates. All of our pipeline specs (including task runs, etc) creates a 2MB yaml file. We push dozens and dozens of these into k8s daily. It works but at the same time our usage of Tekton is more or less as a glorified alternative to batch jobs which works because batch jobs _still_ don't have a proper sidecar capability and also because we rely on the DAG to order dependent taskruns.

If your pipeline is simple, look at Tekton. But if your pipeline is complex... still look at Tekton but expect to do some work. Once you get a good workflow though you can you can scale your pipelines as easily as you can a deployment in k8s. We use node autoscaling and preemptibles (Tekton can retry if a task disappears due to node reclamation) to manage our CI costs quite effectively.

Re: Write Gitlab CI Pipelines in Python Code

#42
> “We use bamboo at my job, and it's java that generates a yaml file that is then shoved into bamboo. It's a completely shitshow.”

> “What I have done is generate the yaml programmatically and this gets returned from the web server. Less than ideal but it at least allows dynamic creation”

They amount of polarization in this comment section is making me dizzy.

Re: Write Gitlab CI Pipelines in Python Code

#43
post #19

Another step in the endless cycle of configuration vs code. It's not an accident that we are in a deep cycle of constrained configuration languages (yaml/json/etc etc). People chose to go there because before that we had a cycle of using programming languages and people hated it, for all sorts of good reasons. Now I see we are on the way back into adding wrappers around the static config files, to turn them back into…

You make a good point.

As a developer who also dabbed in devops, I hate CI-side scripting with a passion.

The last place I've worked a few years back had about 20 interdependent Jenkins jobs per project. During a build, a job would break another job who would break another job but not successively fast enough to intervene so the majority of the time of the devops guru was spent on making hacks and fixes everywhere, thus fueling the endless cycle of madness. Middle management were aware of the problem but they never could say no to new aggressive timelines so here we were but I digress.

For me a CI server is a way to automate tasks so that 1) devs' time is saved 2) all versions are release worthy 3) human mistakes are kept to a minimum 4) a public record is kept 5) long and boring tasks such as packaging releases, generating code coverage and running the static code analyzer do not bother devs and are done periodically.

What CI should not do: 1) do things that devs can't do 2) crash 3) run nondeterministic builds and tests 4) be understandable by only one guy named Brent (wink wink Phoenix Project).

A typical CI script should limit itself to a simple workflow: checkout revision, get dependencies, build, test, release; and those should all be things that can be done, tested and modified and debugged on a common developing environment. Anything else is just loaning time from the future.

Re: Write Gitlab CI Pipelines in Python Code

#44
post #19

Another step in the endless cycle of configuration vs code. It's not an accident that we are in a deep cycle of constrained configuration languages (yaml/json/etc etc). People chose to go there because before that we had a cycle of using programming languages and people hated it, for all sorts of good reasons. Now I see we are on the way back into adding wrappers around the static config files, to turn them back into…

In my opinion generating configuration from Python (or any language with a robust standard library) is still a win if it means less Ops and DevOps engineers are stringing together convoluted bash scripts that torture sed/awk/jq/yq to obscene lengths.

While it is true that Python scripts are far more superior to cryptic bash scripts, those scripts shouldn't be on the CI's side. Nothing wrong having build.py and test.py and the others, but there are no good reasons for them to be executable only by the CI. Debugging CI scripts is just asking for non-stop pager duty.

Re: Write Gitlab CI Pipelines in Python Code

#45
post #19

Another step in the endless cycle of configuration vs code. It's not an accident that we are in a deep cycle of constrained configuration languages (yaml/json/etc etc). People chose to go there because before that we had a cycle of using programming languages and people hated it, for all sorts of good reasons. Now I see we are on the way back into adding wrappers around the static config files, to turn them back into…

I think the only exit to this cycle is something like dhall, which adds features like functions and imports, but is "total" / forbids side-effects. https://dhall-lang.org/

Re: Write Gitlab CI Pipelines in Python Code

#46
post #19

Another step in the endless cycle of configuration vs code. It's not an accident that we are in a deep cycle of constrained configuration languages (yaml/json/etc etc). People chose to go there because before that we had a cycle of using programming languages and people hated it, for all sorts of good reasons. Now I see we are on the way back into adding wrappers around the static config files, to turn them back into…

In my opinion generating configuration from Python (or any language with a robust standard library) is still a win if it means less Ops and DevOps engineers are stringing together convoluted bash scripts that torture sed/awk/jq/yq to obscene lengths.

You can call your own Python script from the pipeline, instead of using sed/awk/etc., right?

Re: Write Gitlab CI Pipelines in Python Code

#47
post #19

Another step in the endless cycle of configuration vs code. It's not an accident that we are in a deep cycle of constrained configuration languages (yaml/json/etc etc). People chose to go there because before that we had a cycle of using programming languages and people hated it, for all sorts of good reasons. Now I see we are on the way back into adding wrappers around the static config files, to turn them back into…

I think the only exit to this cycle is something like dhall, which adds features like functions and imports, but is "total" / forbids side-effects. https://dhall-lang.org/

Or cuelang

Re: Write Gitlab CI Pipelines in Python Code

#48
post #26
post #7

Earlier quoted context omitted.

Totally agree. I've never used Bazel; it sounds a lot like Nuke. I had a coworker whose job was to maintain the CI. His commit messages would look like this sometimes: > Fix CI issue with blah blah blah > Hmm that didn't work lets try something from stackoverflow > Build fix > Build fix please work > Please > I hate my life > I am tired and hungry, I want to go home > Stupid yaml The CTO would call him like a week la…

The problem in C++ land (my land) is all your dependencies are probably using different build systems. Do you wan to migrate all your third party libs to Bazel, or just hack up a few lines of CI yaml to call the authors build system? I lean on gitlab yaml quite heavily and it feels quite effortless

We vendored all of our third party dependencies into our Bazel build. There were a lot and it was a giant PITA but over a multi-year horizon it was worth it. That doesn't mean it's the right choice for every business but it paid off for us.

Re: Write Gitlab CI Pipelines in Python Code

#49
post #41

Earlier quoted context omitted.

Check out tekton CI ( https://tekton.dev/ ), it's a Kubernetes operator to run a CI pipeline that's defined as commands running inside any container. Use any language, any commands, etc--as long as you can get a container image, you're good to go. There's a growing set of community created and curated actions to do common things too: https://github.com/tektoncd/catalog Yeah you need a k8s cluster, but even a simple k…

We use Tekton to manage our CI pipeline and I agree that the way it enforces very little structure is a strength. On the other hand it's new enough that if you need to stretch its capabilities you are going to have to get creative. The primitives it has are nice, but they have their limits. For instance, if running a bunch of parallel tasks, collating results on a PV is out the window unless your cluster supports mul…

> Running gsutil is easy enough, but it means you are pushing logic into your scripts and not declaring steps in the pipeline definition.

Some other comments here have argued for pushing as much logic as possible into your scrips, so that they can be tested without the CI system. What's the downside of doing this?

Re: Write Gitlab CI Pipelines in Python Code

#50
post #19

Another step in the endless cycle of configuration vs code. It's not an accident that we are in a deep cycle of constrained configuration languages (yaml/json/etc etc). People chose to go there because before that we had a cycle of using programming languages and people hated it, for all sorts of good reasons. Now I see we are on the way back into adding wrappers around the static config files, to turn them back into…

I think the only exit to this cycle is something like dhall, which adds features like functions and imports, but is "total" / forbids side-effects. https://dhall-lang.org/

YTT is pretty nice too and basically glues star lark and yaml together.
Post reply on HN