Many automated vendor/package management tools will not automate pulling newer changes from upstream. If this was instead a simple a read-only version/tag, it is easy for those tools to provide upgrade/update path.
Do I do this for hobby projects? No, of course not. If my toy projects break, meh. But for production? Where breakage actually costs money? Damn right I do.
It's not only breakage, though. You want a hermetic build system, so you can build software reproducibly and consistently. There are few things more "fun" than building "the same" code on two machines, and one executable has a bug while the second doesn't. (OK. Compiler bugs are even more fun)
There is no bright line delimitating what's on the "critical path" and what's not. Your servers? The electric grid? The datacenter? The backbone(s) it's connected to? The judicial system making contracts enforceable? NATO? Name any two that straddle the line, and anybody can come up with something in between them, because it's a continuum.
What's the chance of the grid going down? What's the cost of it? Is the expected value significantly higher than a power generator? Congrats, you just bought a power generator.
Backbone down would cause you huge financial losses? Well, whaddaya say, let's build more backbone.[1]
Any redundancy that costs significantly less than the losses it mitigates will be built. The only reason we're not seeing a private NATO yet is that it costs more than pretty much any company makes. But 5,000 people security forces? Damn skippy those exist[2]
[1] https://engineering.fb.com/data-center-engineering/building-... [2] https://www.businessinsider.com/facebook-off-duty-police-off...
It's not unreasonable to be more concerned about an open source library disappearing than say, postgresql or mysql disappearing. No macho posturing required.
Let's say I'm working front-end web development. My "critical path" might include: js bundler, some kind of application framework, various libs, etc. The scope of my work (and authority/responsibility) informs what I can reasonably have under my control.
https://en.wikipedia.org/wiki/Not_invented_here
?
> It's not a programming library where optimizations are created or we fixed a security vulnerability (though I suppose that can come up ).
But it's a service provided by a paid-for entity which has support which you pay for. If it doesn't work, you let support know....
Anything you use in a critical path you should control. If you're managing your own fork, nobody will inject bad code except yourself.
Just my 2 cents. Also, the things that github 3rd party actions are doing is usually not that complicated. I mean how many different ways can you publish a docker image or deploy an artifact to S3. Once it works, it either works or doesn't. It's not a programming library where optimizations are created or we fixed a security vulnerability (though I suppose that can come up ).
Sorry minor rant. food for thought.