Conversation
We started vendoring dependencies because this was a practice that the Go community had for a while now to: 1. Speed up builds - no need to fetch dependencies every time; 2. Guard against 3rd-party downtime - CI passes even if hosts such as `gopkg.in` are down, or if someone deletes their GitHub repo/account hosting a particular module. With Go 1.13 and GitHub Actions, however, we have these problems solved for free: - The built-in goproxy caches dependencies and speeds up downloads; - Octofactory ensures that dependencies are cached on our own infrastructure, guarding us from 3rd-party downtime. With all this in mind, I feel that we don't have to require vendoring dependencies anymore.
|
i am very supportive of this! possibly a dumb question, but why wouldn't this PR also remove the |
probablycorey
left a comment
probablycorey
left a comment
There was a problem hiding this comment.
I am pro this idea and just learned about Octofactory. Are we using Octofactory in our actions that build the app?
Good question! Because we've checked into git so many different files that we ultimately don't want to keep (
Not explicitly, but we automatically benefit from it. It also enables us to potentially use any private |
YES! Let's do it! |
|
I'm fine with this! Seems better to do it now than later and I don't mind force resetting. |
feat: introduce repo, branch and machine flags for ghcs create
3 participants
We started vendoring dependencies because this was a practice that the Go community had for a while now to:
gopkg.inare down, or if someone deletes their GitHub repo/account hosting a particular module.With Go 1.13 and GitHub Actions, however, we have these problems solved for free:
With all this in mind, I feel that we don't have to require vendoring dependencies anymore.