> You want a CI pipeline, so the junior developer can't just break prod because they forgot to run the tests before pushing.

Make them part of your build first. Tagging a release? Have a documented process (checklist) that says 'run this, do that'. Like how in a Java Maven build you would execute `mvn release:prepare` and `mvn release:perform`, which will execute all tests as well as do the git tagging and anything else that needs doing.

Scale up to a CI pipeline once that works. It is step one for doing that anyway.

▲

BlindEyeHalo 2 days ago | parent [-]

Why not do a CI pipeline from the beginning instead of relying on trust that no one ever forgets to run a check, considering adding CI is trivial with gitlab or github.

▲

9dev a day ago | parent | next [-]

Because it adds friction, and whoever introduces that CI pipeline will be the one getting messages from annoyed developers, saying "your pipeline isn't working again". It's definitely a source of complexity on its own, so something you want to consider first.

▲

spoiler a day ago | parent | next [-]

U agree it adds a bit of complexity, but all code adds complexity.

Maybe interacted with CIs too much and it's Stockholm syndrome, but they are there to help tame and offload complexity, not just complexity for complexity'a sake

▲

9dev a day ago | parent [-]

> they are there to help tame and offload complexity, not just complexity for complexity'a sake

Theoretically. Practically, you're hunting for the reason why your GitHub token doesn't allow you to install a private package from another repository in your org during the build, then you learn you need a classic personal access token tied to an individual user account to interact with GitHub's own package registry, you decide that that sounds brittle and after some pondering, you figure that you can just create a GitHub app that you install in your org and write a small action that uses the GitHub API to create an on-demand token with the correct scopes, and you just need to bundle that so you can use it in your pipeline, but that requires a node_modules folder in your repository, and…

Oh! Could it be that you just added complexity for complexity's sake?

	▲	spoiler a day ago \| parent [-]
		Uh, I've used the package repository with GitHub, and I don't remember having to do this! So, I'm not entirely sure what's happening here. I think this might be accidental complexity because there's probably a misconfiguration somewhere... But on that point I agree, initial set-up can be extremely dauntin due to the amoun of different technologies that interact, and requires a level of familiarity that most people don't want to have with these tools. which is understandable; they're a means to an end and Devs don't really enjoys playing with them (DevOps do tho!). I've had to wear many hats in my career, and was the unofficial dedicated DevOps guy in a few teams, so for better or worse had to grow familiar with them. Often (not always) there's an easier way out, but spotting it through the bushes of documentation and overgrown configuration can be annoying.

▲

pjc50 a day ago | parent | prev [-]

I'm aware of how much overhead CI pipelines can be, especially for multiple platforms and architectures, but at the same time developing for N>1 developers without some sort of CI feels like developing without version control: it's like coming to work without your trousers on.

	▲	9dev a day ago \| parent [-]
		Yeah, that was my entire point really—there's some complexity that's just warranted. It's similar to a proper risk assessment analysis: The goal isn't to avoid all possible risks, but accepting some risk factors as long as you can justify them properly. As long as you're pragmatic and honest with what you need from your CI setup, it's okay that it makes your system more complex—you're getting something in return after all.

▲

fragmede a day ago | parent | prev [-]

Because then you're wasting time trying to quote bash inside of yaml juuuust right to get the runners to DTRT.

Okay no but seriously, if you're not being held back by how slow GitHub CI/Gitlab runners are, great! For others they're slow as molasses and others in different languages with different build systems can run an iteration of their build REPL before git has even finished pushing, nevermind waiting for a runner.