6 ms·

I don't see any of those as reasons to commit dependencies to the same VCS repo your source control lives in. Your first point is particularly laughable. If yo

I don't see any of those as reasons to commit dependencies to the same VCS repo your source control lives in. Your first point is particularly laughable. If your network connection to the internet is down and you're a SaaS provider, you're probably going to need to fix that before you can roll out a fix to your hosted software. That said, they're all good points to consider when building out a deployment pipeline, and in general mirroring your dependencies is a great idea. But committing a vendor directory is a poor solution/mitigation for most of those risks.

TheSwordsman 7y ago
I'm not sure a solution that solves 100% of the problems, with minimal to no side effects, is a poor solution.
- Groxx 7y ago
  There are definitely downsides - a gigantic git repo is a big one. Lengthy clones, far slower git operations, etc. Many projects I've seen go this route will exceed 10s or 100s of gigabytes pretty quickly, and git is very unhappy about sizes like that.
AYBABTME 7y ago
How is it a poor solution? It is extremely simple, pragmatic and effective.
- sigmonsays 7y ago
  I dont think its a poor solution. I have had great success keeping all of GOPATH in git. Its just easier to deploy new packges. The build machine doesn't even need internet access at this point.
ownagefool 7y ago
They themselves are not, but lets look at another consideration. How will you catch a backdoor added to one of your dependencies? - Scan them and hope someone else noticed and reported before you used it? - Assume your team mates reviewed them when they were updated? - Add SIEM like capabilities and monitor network connections? It should really be all 3. There are counter points of course, but if you vendor them, they'll in a PR and reviewed just the same as the rest of your code. Of course, where do you stop? You trust your distro to do the right thing and you don't review that code, etc. So the more generic question is why do you trust the golang modules you use?
programd 7y ago
> Your first point is particularly laughable. If your network connection to the internet is down and you're a SaaS provider, you're probably going to need to fix that before you can roll out a fix to your hosted software. Don't assume that your SaaS runs on the same network as your build machines. In most cases this is not the case - or at least it shouldn't be. Your SaaS might be broken in some way, you're trying to create a build to fix it on your secure corp network and your connectivity to the Net disappears. And it's 3 AM in San Francisco and everyone who can fix it is asleep, and meanwhile your European customers are not happy. Let's be clear. You can mitigate the effect of all these problems one way or another. But the mitigations are easier if you have less moving parts and less dependencies on systems you don't control. Lets face it, ultimately it all comes down to limiting your business risk at least cost (because money). One simple way to do that is if your build environment travels with your code down the years.
- ndarwincorn 7y ago
  > Don't assume that your SaaS runs on the same network as your build machines. That wasn't the assumption. It's laughable because under any condition of where your hosting and build infrastructure live, you'll need to restore your internet connection before you can deploy whatever software fix you're trying to ('deploy' in the sense that your customers have access to the deployed fix).
dewey 7y ago
> I don't see any of those as reasons to commit dependencies to the same VCS repo your source control lives in. Why not? What's the downside except having a "update dependency" commit from time to time. It's a great solution to always have your dependencies at hand, offline and even versioned. Makes it easy to see when a bug got introduced by a dependency or roll back an update. Especially for projects that don't have a build pipeline, cached dependencies or just smaller dependencies that aren't very well backed up from other people. I think it's a great way to make sure things are still running after a few years (personal projects) and everything still works without having to hunt down some dependencies or find alternative mirrors.
- SamWhited 7y ago
  > What's the downside except having a "update dependency" commit from time to time. This isn't a downside, it's a chance to vet and code review your dependencies which you should be doing anyways (but nobody does).

TheSwordsman 7y ago

I'm not sure a solution that solves 100% of the problems, with minimal to no side effects, is a poor solution.

Groxx 7y ago
There are definitely downsides - a gigantic git repo is a big one. Lengthy clones, far slower git operations, etc. Many projects I've seen go this route will exceed 10s or 100s of gigabytes pretty quickly, and git is very unhappy about sizes like that.

AYBABTME 7y ago

How is it a poor solution? It is extremely simple, pragmatic and effective.

sigmonsays 7y ago
I dont think its a poor solution. I have had great success keeping all of GOPATH in git. Its just easier to deploy new packges. The build machine doesn't even need internet access at this point.

ownagefool 7y ago

They themselves are not, but lets look at another consideration. How will you catch a backdoor added to one of your dependencies? - Scan them and hope someone else noticed and reported before you used it? - Assume your team mates reviewed them when they were updated? - Add SIEM like capabilities and monitor network connections? It should really be all 3. There are counter points of course, but if you vendor them, they'll in a PR and reviewed just the same as the rest of your code. Of course, where do you stop? You trust your distro to do the right thing and you don't review that code, etc. So the more generic question is why do you trust the golang modules you use?

programd 7y ago

> Your first point is particularly laughable. If your network connection to the internet is down and you're a SaaS provider, you're probably going to need to fix that before you can roll out a fix to your hosted software. Don't assume that your SaaS runs on the same network as your build machines. In most cases this is not the case - or at least it shouldn't be. Your SaaS might be broken in some way, you're trying to create a build to fix it on your secure corp network and your connectivity to the Net disappears. And it's 3 AM in San Francisco and everyone who can fix it is asleep, and meanwhile your European customers are not happy. Let's be clear. You can mitigate the effect of all these problems one way or another. But the mitigations are easier if you have less moving parts and less dependencies on systems you don't control. Lets face it, ultimately it all comes down to limiting your business risk at least cost (because money). One simple way to do that is if your build environment travels with your code down the years.

ndarwincorn 7y ago
> Don't assume that your SaaS runs on the same network as your build machines. That wasn't the assumption. It's laughable because under any condition of where your hosting and build infrastructure live, you'll need to restore your internet connection before you can deploy whatever software fix you're trying to ('deploy' in the sense that your customers have access to the deployed fix).

dewey 7y ago

> I don't see any of those as reasons to commit dependencies to the same VCS repo your source control lives in. Why not? What's the downside except having a "update dependency" commit from time to time. It's a great solution to always have your dependencies at hand, offline and even versioned. Makes it easy to see when a bug got introduced by a dependency or roll back an update. Especially for projects that don't have a build pipeline, cached dependencies or just smaller dependencies that aren't very well backed up from other people. I think it's a great way to make sure things are still running after a few years (personal projects) and everything still works without having to hunt down some dependencies or find alternative mirrors.

SamWhited 7y ago
> What's the downside except having a "update dependency" commit from time to time. This isn't a downside, it's a chance to vet and code review your dependencies which you should be doing anyways (but nobody does).