from Hacker News

Write Gitlab CI Pipelines in Python Code

by DrSarez on 4/29/21, 8:47 PM with 95 comments

• by zmmmmm on 4/29/21, 11:24 PM

  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 programming languages. This is happening all over the place - because guess what, it turns out, people hate static config files too, for all sorts of good reasons.

  I am not sure if we will ever reach a compromise here or if we are just going to have to put up with endless change and churn because nobody is ever happy or at least willing to just settle for things that are "ok" but not "perfect".

• by kmstout on 4/29/21, 10:50 PM

  Several weeks ago I poked around Github's CI workflow references. It seems that there's a clear path for crafting a workflow that simply grabs the text of a each issue (as it's submitted) and appends it to the documentation before closing the issue, perhaps marking it as "expected behavior". In short, an evening of tinkering could automatically turn all of a project's bugs into features for the foreseeable future.

  This would represent a quantum leap in software quality assurance.

• by octopoc on 4/29/21, 9:47 PM

  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 ability to download benchmark results from previous commits so that I can generate trend graphs and publish them in the build results.

  To do this right the CI system would have to have an API using REST, GraphQL, gRPC or some such API format that generates clients in many languages. That way they don't have to maintain bindings in every language.

  [1] https://nuke.build/

• by LennyWhiteJr on 4/30/21, 3:42 AM

  It's almost like we've turned yaml into some sort of primitive assembly file that must be compiled by a higher-order language. What was once created for human readability, has now turned into a machine generated and machine parsed format.

• by freetime2 on 4/30/21, 7:45 AM

  > We started this project because of Gitlab CI yaml files growing over thousands of lines.

  Is this typical? All of our Gitlab CI files are well under 100 lines. What sorts of things are these pipelines doing that require so much configuration?

  Our CI steps are basically:

  * Build

  * Run some static analysis

  * Test

  * Publish build artifacts

  With each step taking only a few lines. Most of the “heavy lifting” is managed by other tools like npm, or some scripts we have checked into the project, and our CI process just kicks off those steps.

• by remram on 4/29/21, 11:51 PM

  I think if we're going that way, it would be nice to have a single library that can generate configurations for multiple CI systems (GitLab CI, GitHub Actions, Jenkins, CircleCI, etc)

• by kissgyorgy on 4/30/21, 8:08 AM

  It seems like a lot of people don't understand that having a DECLARATIVE language/configuration/whatever such a huge advantage it's insane. It's so easy to write, you can never make logical mistakes, avoid all kind of bugs, it's just easy to learn and you can just write the desired result.

  I never understood these project where somebody makes a very easy declarative thing and makes it imperative.

  Programming in Python is order of magnitude "harder" and error prone than writing a simple YAML file.

• by CSDude on 4/30/21, 10:35 AM

  I have made something similar for Tekton (Kubernetes) with Jsonnet, https://mustafaakin.dev/posts/2020-04-26-using-jsonnet-to-ge... but the eternal cycle of configuration vs code is always bothering me in every few years and make me question myself.

• by zie on 4/29/21, 10:29 PM

  This is cool, but I'd rather my CI jobs are just k8s or nomad or systemd jobs. Then the code we deploy is the same as the code we use to build, and it doesn't matter WHAT you do in build land, go nuts and do whatever you want.

  CI systems will either grow into general purpose code runners or they will wither and die.

• by nhoughto on 4/29/21, 9:23 PM

  Reminds me of the original atlassian bamboo pipeline as code impl that had you write the pipeline as Java or Groovy, can’t remember specifically. They got dunked on for it not being a declarative file.

  Now we’ve got a pipeline being defined by a declarative file being generated by code.

• by nerdbaggy on 4/29/21, 10:01 PM

  Gitlab can load its ci file from a remote web server. 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

• by aiisjustanif on 4/30/21, 3:58 AM

  > “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.