How do you keep your modules up-to-date?

[James Hartig]

What's the best way to automatically always pull the latest release/commit for certain repos? We use gerrit internally so all of our import paths for internal packages start with something like gerrit.corp. We have over 50 different repos and it would be painstaking to have to update (pull latest, run go get, commit, get review) every single one of those repos whenever an internal package was updated with a minor change.

How do others solve the problem of outdated modules? Do developers frequently commit "Go modules updated" changes where they just update the go.mod? Is there a process defined where every repo has their deps updated once a month/week/etc?

1) Would it be better to just remove gerrit.corp lines from go.mod before it's committed so the dependencies are always resolved at run-time by CI?

2) Should our CI system look at go.mod and run go get -u for each gerrit.corp line as part of the build/test pipeline?

3) Or should we just run "go get -u ..." on every CI build to always have the latest minor updates of all modules?

[Marcin Romaszewicz]

I have the same kind of setup at my company, and we use go modules in the same way that we would use public modules. We periodically do a "go get -u" to update them. Jenkins does that once a week, so at worst, we're a week behind. If someone needs to manually pull in changes more urgently, they can just run the "go get" themselves and commit go.mod and go.sum. It works well. Don't be too smart with this stuff, and just let the module system work as intended. When you use private repos, it's a pain in the butt to have the auth work, but it sounds like you've got that solved.

-- Marcin

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/909a63a6-0e02-4129-bf5d-efadb353acf4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[James Hartig]

Marcin,

Thanks for the reply! So do you have Jenkins run go get -u, run tests, and then commit the changes? Does it automatically only update private repos or does it update both? Is there any review process each week to validate the updates?

I'm leaning towards a combination of what you suggested and what I mentioned as 2: Have CI run go get -u for all private repos before the build starts. So weekly would update all deps and each build would update all private deps.

On Thursday, May 30, 2019 at 12:19:28 PM UTC-4, Marcin Romaszewicz wrote:

I have the same kind of setup at my company, and we use go modules in the same way that we would use public modules. We periodically do a "go get -u" to update them. Jenkins does that once a week, so at worst, we're a week behind. If someone needs to manually pull in changes more urgently, they can just run the "go get" themselves and commit go.mod and go.sum. It works well. Don't be too smart with this stuff, and just let the module system work as intended. When you use private repos, it's a pain in the butt to have the auth work, but it sounds like you've got that solved.

-- Marcin

On Thu, May 30, 2019 at 7:55 AM James Hartig <faste...@gmail.com> wrote:

What's the best way to automatically always pull the latest release/commit for certain repos? We use gerrit internally so all of our import paths for internal packages start with something like gerrit.corp. We have over 50 different repos and it would be painstaking to have to update (pull latest, run go get, commit, get review) every single one of those repos whenever an internal package was updated with a minor change.

How do others solve the problem of outdated modules? Do developers frequently commit "Go modules updated" changes where they just update the go.mod? Is there a process defined where every repo has their deps updated once a month/week/etc?

1) Would it be better to just remove gerrit.corp lines from go.mod before it's committed so the dependencies are always resolved at run-time by CI?

2) Should our CI system look at go.mod and run go get -u for each gerrit.corp line as part of the build/test pipeline?

3) Or should we just run "go get -u ..." on every CI build to always have the latest minor updates of all modules?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.