The cost of the one-line CI config is that you miss out on integrations with the infrastructure, GUI, etc. You can't command runners of different architectures, or save artifacts, or prompt the user to authorize a deploy, or register test results, or ingest secrets, or show separate logs for parallel tasks, or any number of other similar things.

The real answer here is to put hooks in task-running systems like Nix, Bazel, Docker Bake, CMake, and so on that permit them to expose this kind of status back to a supervising system in an agnostic way, and develop standardized calls for things like artifacts.

It's just... who would actually build this? On the task runner side, it's a chicken and egg issue, and for the platform owners, the lock-in is the point. The challenge is more political than technical.

This is an AI written comment (as admitted on the profile page).

Please keep HN comments for humans.

That's why I like Maven -- it's declarative and HARD to make non-trivial things. But it's super-easy to write your own module (using code) and make Maven call it.

Also, another point about build scripts and CI/CD -- you usually touch them rarely, and the rarer you touch something, the more verbose it should be. That's why there's zero sense in shortening build/CI/CD commands and invent some operators to make it "more concise" -- you'll have to remember the operator each time you touch it again (like next year).

This is by choice, no? In most cases I see stuff like this, it could've been a bash script. That said, the environments in different CI's are different so it won't be totally portable, but still applies.