I'm thinking before we build a CI/CI pipeline, make sure there is a Makefile. Why have they gone out of style?
The CD Pipeline Manifesto
11–20 of 51 posts
Re: The CD Pipeline Manifesto
#12[deleted]
Re: The CD Pipeline Manifesto
#13I'm thinking before we build a CI/CI pipeline, make sure there is a Makefile. Why have they gone out of style?
Not sure but my guess is because they aren't a good fit for many languages. If you need a task runner then often languages will have a built in option or there are better alternatives than Make. If you need a build system then Make isn't a good fit for a lot of modern languages.
Re: The CD Pipeline Manifesto
#14I'm thinking before we build a CI/CI pipeline, make sure there is a Makefile. Why have they gone out of style?
Not sure but my guess is because they aren't a good fit for many languages. If you need a task runner then often languages will have a built in option or there are better alternatives than Make. If you need a build system then Make isn't a good fit for a lot of modern languages.
I’ve been using earthly a lot lately and its general value prop is simple: it turns out that if Buildkit is your primary build tool that Make targets can almost always be represented as OCI image layers. The killer feature IMO is that its syntax is familiar enough to end users of both Make and Dockerfiles that engineers tend to be willing to onboard to it. A lot of these other solutions that use proprietary DSL’s struggle to cover every use case, and the implementations in turing complete typical language SDK approach often forces you into analysis paralysis if there is no existing pattern.
Re: The CD Pipeline Manifesto
#15None of these are a problem anymore since the advent of Nix.
Re: The CD Pipeline Manifesto
#16I'm thinking before we build a CI/CI pipeline, make sure there is a Makefile. Why have they gone out of style?
If I want to build and test a golang app and push it to a container repository, what value does a makefile provide over go build && docker push?
All the tools do their own dependency tracking already (unfortunately).
Re: The CD Pipeline Manifesto
#17I commend anyone who’s taking a hard look at our current CI/CD practices. Good work! Succinctly stating the problems is easier said than done. I believe https://dagger.io checks all these manifesto boxes and more. At least that’s where I’m focusing my attention.
My company is currently adopting this and I don't see the appeal yet - likely from a lack of knowing much about it.
I added it to a side project just to get familiar and it added quite a few sdk files and folders to my project, and lots of decorators. It also required Docker and yadda yadda yadda.
I just could not justify using it compared to just running some regular Typescript file with Bun (or, in a different project, `go run cmd/ci/main.go`)
Re: The CD Pipeline Manifesto
#18I'm thinking before we build a CI/CI pipeline, make sure there is a Makefile. Why have they gone out of style?
My struggle with Make and bash is that they're not very expressive - maybe that's something we want in our CIs, but I've always preferred writing an actual program in that program's native language for CI/CD, even if it has to shell out some commands every now and again.
Re: The CD Pipeline Manifesto
#19I'm thinking before we build a CI/CI pipeline, make sure there is a Makefile. Why have they gone out of style?
If I want to build and test a golang app and push it to a container repository, what value does a makefile provide over go build && docker push? All the tools do their own dependency tracking already (unfortunately).
Honestly I like it just to keep it as a command runner with the needed flags. Then in the unholy YAML there's just make build, make test, etc
Re: The CD Pipeline Manifesto
#20FTA:
> The Fix: Use a full modern programming language, with its existing testing frameworks and tooling.
I was reading the article and thinking myself "a lot of this is fixed if the pipeline is just a Python script." And really, if I was to start building a new CI/CD tool today the "user facing" portion would be a Python library that contains helper functions for interfacing with with the larger CI/CD system. Not because I like Python (I'd rather Ruby) but because it is ubiquitous and completely sufficient for describing a CI/CD pipeline.
I'm firmly of the opinion that once we start implementing "the power of real code: loops, conditionals, runtime logic, standard libraries, and more" in YAML then YAML was the wrong choice. I absolutely despise Ansible for the same reason and wish I could still write Chef cookbooks.