Test run in https://github.com/containers/container-libs/actions/runs/17303389306/job/49120031490

cc @jankaluza @mtrmac

LGTM

Looks like #292 worked as well and added the storage label so that is good.

Can Renovate be configured to do a go work-wide update?

I though it already did, at least when I looked at it with @jankaluza why the workspace vendoring was broken. It definably has workspace aware code so maybe some extra config option.

Mhh if I look at the logs https://developer.mend.io/github/containers/container-libs/-/job/d0c5143f-0e63-4056-b583-398cdd67ac40 it definitely claims it runs go work sync, I guess it might be the same issue with the vendor dir where the resulting diff is not added to the commit

renovatebot/renovate#37653

Yes, previously #283 did sync things — But that one had a reason to update */go.* anyway.

Looking at the renovate config I am not sure we can make it work, first our config is wrong as we still ask for vendoring https://github.com/containers/container-libs/blob/d08c7eec33b7997c1a50a4d79e00b312dc9fcb53/.github/renovate.json5#L54

but when we remove it will no longer run go work sync as this is put inside the useVendor condition.
https://github.com/renovatebot/renovate/blob/6e00de5daf57f7ab240b0d085b4edd469f738f30/lib/modules/manager/gomod/artifacts.ts#L291
you can even see it the current log it still runs go work vendor.

So to me I guess renovate is just not working no matter what config we use, I guess best case we just make a PR to renovate to fix the behavior. I am not sure if the discussion will gain much traction otherwise, the repo seems quite busy.

For a while, it wouldn’t be so bad for us to manually amend every Renovate-filed PR with a go work sync. Longer-term, it would be an annoyance.

I agree contributing a PR to Renovate upstream would be the cleanest approach.

We could, also, give up on keeping the repo consistent with go work sync (and I guess add go.work.sum to .gitignore). That would be consistent with how it used to work, where we sync indirect dependencies only when tagging releases. It’s clearly worse than keeping the workspace synchronized.

I guess the decision ~depends on a guess how much effort+time it would take to improve Renovate.

Dropped the commit which added go work sync to the Makefile, however as it seems just go tidy in eahc module will still populate the go.work.sum file

tree is dirty, please run "make tidy" and commit all changes.

 M go.work.sum

---------------------- Diff below ----------------------

diff --git a/go.work.sum b/go.work.sum
index 614095b..ca28494 100644
--- a/go.work.sum
+++ b/go.work.sum
@@ -114,6 +114,7 @@ github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0/go.mod h1:W
 github.com/golang/protobuf v1.4.0/go.mod h1:jodUvKwWbYaEsadDk5Fwe5c77LiNKVO9IDvqG2KuDX0=
 github.com/golang/protobuf v1.4.1/go.mod h1:U8fpvMrcmy5pZrNK1lt4xCsGvpyWQ/VVv6QDs8UjoX8=
 github.com/golang/protobuf v1.4.3/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI=
+github.com/golang/protobuf v1.5.0/go.mod h1:FsONVRAS9T7sI+LIUmWTfcYkHO4aIWwzhcaSAoJOfIk=
 github.com/golang/snappy v0.0.4/go.mod h1:/XxbfmMg8lxefKM7IXC3fBNl/7bRcc72aCRzEWrmP2Q=
 github.com/google/certificate-transparency-go v1.3.1/go.mod h1:gg+UQlx6caKEDQ9EElFOujyxEQEfOiQzAt6782Bvi8k=
 github.com/google/go-cmp v0.2.0/go.mod h1:oXzfMopK8JAjlY9xF4vHSVASa0yLyX7SntLO5aqRK0M=
@@ -121,6 +122,7 @@ github.com/google/go-cmp v0.3.1/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMyw
 github.com/google/go-cmp v0.4.0/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
 github.com/google/go-cmp v0.5.0/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
 github.com/google/go-cmp v0.5.3/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
+github.com/google/go-cmp v0.5.5/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE=
 github.com/google/s2a-go v0.1.9/go.mod h1:YA0Ei2ZQL3acow2O62kdp9UlnvMmU7kA6Eutn0dXayM=
 github.com/google/uuid v1.1.2/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo=
 github.com/googleapis/enterprise-certificate-proxy v0.3.4/go.mod h1:YKe7cfqYXjKGpGvmSg28/fFvhNzinZQm8DGnaburhGA=
@@ -282,6 +284,8 @@ google.golang.org/protobuf v1.22.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2
 google.golang.org/protobuf v1.23.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
 google.golang.org/protobuf v1.23.1-0.20200526195155-81db48ad09cc/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU=
 google.golang.org/protobuf v1.25.0/go.mod h1:9JNX74DMeImyA3h4bdi1ymwjUzf21/xIlbajtzgsN7c=
+google.golang.org/protobuf v1.26.0-rc.1/go.mod h1:jlhhOSvTdKEhbULTjvd4ARK9grFBp09yW+WbY/TyQbw=
+google.golang.org/protobuf v1.33.0/go.mod h1:c6P6GXX6sHbq/GpV6MGZEdwhWPcYBgnhAHhKbcUYpos=
 gopkg.in/ini.v1 v1.67.0/go.mod h1:pNLf8WUiyNEtQjuu5G5vTm06TEv9tsIgeAvK8hOrP4k=
 gopkg.in/tomb.v1 v1.0.0-20141024135613-dd632973f1e7/go.mod h1:dt/ZhP58zS4L8KSrWDmTeBkI65Dw0HsyUHuEVlX15mw=
 honnef.co/go/tools v0.0.0-20190102054323-c2f93a96b099/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4=
Error: Process completed with exit code 1.

So I guess that means renovate PRs would still break on that check thus we cannot merge until renovate gets fixed unless we like to amend all the PRs which I don't

We could explicitly ignore the top-level go.work.sum, and still enforce within-module tidy validation. It’s not as good, maybe still worthwhile.

OTOH if we think Renovate is going to be fixed shortly, it might be easier to wait than to do things twice.

OTOH if we think Renovate is going to be fixed shortly, it might be easier to wait than to do things twice.

Well that is the problem, we cannot know that side. Even if Jan submits a fix, it doesn't mean it gets merged anytime soon. And then we use the hosted mend instance so we get to wait until the fix gets deployed there and who knows how long that will take.

Rebased, since go.work.sum is gitignored this should work fine now and we really should have this CI check running, compare #372

(Looking at https://github.com/containers/container-libs/actions/runs/18659715963/job/53197142461?pr=291 , after setup-go we seem to download quite a few other dependencies, but we don’t save that as a new cache item; it seems that the cache key matches a different job that doesn’t do those downloads; and actions/setup-go doesn’t have an option to let us explicitly differentiate between the various caches. But then again, this is by no means the longest test, so it doesn’t matter; we could do something horribly tacky ugly like add an extra file to cache-dependency-path, let’s not.)

Uh good catch, I think I see what is happening, the git-validation doesn't download any modules out of this repo but uses the same **/go.sum cache key, when that job finished first it uploads the wrong modules from git-validate.
The issue is there is no way to specify a custom script for the cache key, and the modules do not depend on any file in the repo so giving it a random file would be wrong as well.

I guess we don't need to block on it since that would be a pre existing issue but to fix it we would should make git-validate use a different cache at least, unfortunately we cannot skip the saving actions/setup-go#497

Alternatively we group them all in serial into one task instead of having these four currently.

Uh good catch, I think I see what is happening, the git-validation doesn't download any modules out of this repo but uses the same **/go.sum cache key, when that job finished first it uploads the wrong modules from git-validate.
…
but to fix it we would should make git-validate use a different cache at least

I think if git-validation is not actually using **/go.sum then it would be correct for that task to not set cache-dependency-path: "**/go.sum" . (We might consider creating a separate go.{mod, sum} for tools — or, ideally, build/use a git-validation container image and not build it every time.)

I guess we don't need to block on it since that would be a pre existing issue

Oh that is absolutely non-blocking; the 26 seconds make ~no difference to anything, and most importantly, I want to get this check in to prevent the repeat of #372 .

It seems my Renovate PR is now deployed in production. The commit renovatebot/renovate@b50ee3d is introduced in the version 41.135.6 and the one deployed in Mend is 41.143.1.

It seems my Renovate PR is now deployed in production. The commit renovatebot/renovate@b50ee3d is introduced in the version 41.135.6 and the one deployed in Mend is 41.143.1.

Did you test that it works correctly then? If so please make a PR enable vendoring and add go.work.sum back.

(Purely for the record, https://github.com/containers/container-libs/actions/runs/18684685633/job/53274063370?pr=372 confirms that the go tidy check works as desired in #372 .)