fix: tell builder and build-dry about go.sum for go caching

[bobcallaway]

Fixes: #2863

[laurentsimon]

Thanks for the PR / issue @bobcallaway . Do I understand correctly that if the cache becomes contaminated, it would contaminate all the (arch-specific) binaries instead of one? And the contamination would be only for this workflow run, not other runs?

[bobcallaway]

A contaminated cache with the default settings would poison all binaries, and contamination would not be limited to only that workflow run IIUC. You could disable the cache that is on by default in setup-go and use a unique cache key (see https://github.com/actions/cache#creating-a-cache-key) to limit the blast radius but still get reuse across the various jobs depending on how you configure it.

…

On Mon, Oct 16, 2023 at 5:00 PM laurentsimon ***@***.***> wrote: Thanks for the PR / issue @bobcallaway <https://github.com/bobcallaway> . Do I understand correctly that if the cache becomes contaminated, it would contaminate all the (arch-specific) binaries instead of one? And the contamination would be *only* for this workflow run, not other runs? — Reply to this email directly, view it on GitHub <#2864 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVWTJLGCYIJRHXYY3XOYOLX7WN5RAVCNFSM6AAAAAA6CGHEUCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRVGI3DMNJTHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ianlewis]

As @laurentsimon is alluding to, I think our main concern would be how caching affects the build and if the cache could be poisoned from the user's job. I assume the cache is for the whole repo and is reused across jobs? I kind of feel like reusable workflows should be operating from their own cache but could be wrong.

@bobcallaway What is the impact to you and rekor? Does not using cache greatly affect your build times?

It's also worth noting we have this same issue for other builders like the Node.js builder.

[bobcallaway]

If you’re using setup-go, caching is on by default in v4+; if you don’t want that, you should disable it IMO. I think we should talk to GitHub about the scope of caches (org vs project vs workflow) to design it properly. Given that rekor will need to generate 13 variants of two binaries, caching go modules seems like a meaningful optimization.

…

On Mon, Oct 16, 2023 at 7:18 PM Ian Lewis ***@***.***> wrote: As @laurentsimon <https://github.com/laurentsimon> is alluding to, I think our main concern would be how caching affects the build and if the cache could be poisoned from the user's job. I assume the cache is for the whole repo and is reused across jobs? I kind of feel like reusable workflows *should* be operating from their own cache but could be wrong. @bobcallaway <https://github.com/bobcallaway> What is the impact to you and rekor? Does not using cache greatly affect your build times? It's also worth noting we have this same issue for other builders like the Node.js builder. — Reply to this email directly, view it on GitHub <#2864 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVWTJIERPG4O6HA4XTL4XDX7W6EVAVCNFSM6AAAAAA6CGHEUCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRVGQYTGNBVGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[laurentsimon]

So maybe that's an option we can enable in the workflow to let teams opt-in, like we do for go-version and go-version-file?

I think we should talk to GitHub
about the scope of caches (org vs project vs workflow) to design it
properly.

+1