Return another exit code when files need to be updated

[myshkin5]

Great tool! Thanks for creating it!

I would like to integrate gofumpt into my CI/CD pipeline so I want to know if there are changes to make. Maybe a command line option could tell gofumpt to return an error exit code if files need to be rewritten. Or this could be the default behavior with the -d option.

[mvdan]

I actually agree that using gofmt/gofumpt in CI/CD is a bit cumbersome, and there have been proposals to make gofmt -d return a non-zero exit status if there are differences. See golang/go#24230.

We'll already be breaking command-line-usage compatibility with gofmt with #105, so I think we can consider this feature then.

[mvdan]

I actually agree that using gofmt/gofumpt in CI/CD is a bit cumbersome, and there have been proposals to make gofmt -d return a non-zero exit status if there are differences. See golang/go#24230.

I ended up opening another upstream issue to make my case for it.

[mvdan]

Err, why did I not link it here? It's golang/go#46289 :)

[Jacalz]

I think this would be a very good change. For anyone else that want to use it in their CI, I’m currently working around it using this instead:
test -z $(gofumpt -d -e . | tee /dev/stderr)
I hope it can help someone until this has been fixed :)

[NoahHakansson]

I think this would be a very good change. For anyone else that want to use it in their CI, I’m currently working around it using this instead: test -z $(gofumpt -d -e . | tee /dev/stderr) I hope it can help someone until this has been fixed :)

To get rid of the test: too many arguments add "" around it like: test -z "$(gofumpt -d -e . | tee /dev/stderr)" instead

[prologic]

Any chance we'll see a flag for enabling "exit status on differences"? 🤔

[myshkin5]

For what it's worth, we now just use golangci-lint. It runs gofumpt in a "linter" mode (and tons of other linters too): https://golangci-lint.run/usage/linters/#gofumpt

[mvdan]

The chances of this feature being done in gofumpt are pretty much 100%. I just want to be careful about adding features before gofmt does, because if gofmt later adds it and in a different way (e.g. different flag name), then the result will be confusing for everyone.

I've left a comment in golang/go#46289 (comment) trying to nudge things along.