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