Support reproducible builds when using module plugin system

[pimlie]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.
• I agree to follow this project's Code of Conduct

How did you install golangci-lint?

Docker

Your feature request related to a problem? Please describe

When creating a custom golangci-lint build multiple times in a row then the sha256 checksum of the produced binary seems to be different for every build. Even though none of the local config/plugin files changed in between.

This f.e. means that Git considers the binary to be changed after every build.

Describe the solution you'd like

It would be great if custom builds are reproducible, i.e. same input always create same binary output hash.

Describe alternatives you've considered

Don't know of any possible workarounds?

Additional context

Note that using the Module Plugin System is explicitly recommended, hence why Im using this and not the Go Plugin System

Supporter

• I am a sponsor through GitHub or OpenCollective

[ldez]

Hello,

The builds are always different because the build date (used inside the version) is always different.

[ldez]

The date is used to invalidate the cache and identify the binary, so it cannot be removed.

I don't know your process for creating, storing, and using the binary, so I cannot provide recommendations.

[pimlie]

Thanks for the quick reply. Would it be an option to toggle that behaviour so it's at least possible to create reproducible builds? Either by omitting the build specific versions completely or based on some user-defined versioning system (f.e. github commit hashes instead of date)?
And wouldn't it be possible to invalidate build caches manually, that seems more like a design choice then a strict requirement at least?

Part of my gh action workflow is to run some code generator's to ensure that any changes to the generator source are applied / committed. Its too cumbersome to check all individual source files (especially to maintain the source file list), so its easier to just run go generate and run a git status after to see if any files have changed (which would be a build failure).

As it's also somewhat cumbersome to check if any of my local linter plugin source files has changed, Im building the custom linter on every gh action run. As I currently run the linter before the git status check, that check fails atm due to the linter hash changing all the time.

There are ofc many way's I can solve this myself (change order of steps, ignore linter binary in git status check etc) but still feel that reproducible builds would be a nice thing to have :)

[ldez]

Would it be an option to toggle that behaviour so it's at least possible to create reproducible builds? Either by omitting the build specific versions completely or based on some user-defined versioning system (f.e. github commit hashes instead of date)?

No, because this will impact how golangci-lint works.

About the git commit hash, which git commit? If it's the commit of golangci-lint this is not enough and can lead to never invalidating the cache.

And wouldn't it be possible to invalidate build caches manually, that seems more like a design choice then a strict requirement at least?

It is already possible to invalidate the cache, but this is a bad idea to rely on a user action to manage the cache.
This will slow down golangci-lint.

As it's also somewhat cumbersome to check if any of my local linter plugin source files has changed, Im building the custom linter on every gh action run

The hash inside the version (i.e., 47DEQpj8HBSaTImW5JCeuQeRkm5NMpJWZG3hSuFU) is related to local plugin source files, so you don't have to compute it.

golangci-lint has version v2.3.0-custom-gcl-47DEQpj8HBSaTImW5JCeuQeRkm5NMpJWZG3hSuFU built with go1.24.5 from ? on 2025-07-28 12:41:45.066545871 +0000 UTC

Technically, outside local plugins, the .custom.gcl.yml, if used with explicit versions or hashes, is enough to provide "reproducibility".

[pimlie]

Ah ok, thanks for explaining. Will look into some workaround for now then, thanks again! 😸