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 
> <javascript:>> 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 <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/909a63a6-0e02-4129-bf5d-efadb353acf4%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/909a63a6-0e02-4129-bf5d-efadb353acf4%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7e16bf06-8fd2-4c50-939f-6c4d44be917a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to