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.