New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: add mod tidy -check #27005
Comments
Non-zero exit codes are usually for errors, so having it behave like this by default would be counter-intuitive. Perhaps it could have something similar to gofmt, which has the |
If the files are successfully added why wouldn't you want to see a 0 status code? This means that the following script would fail: #!/usr/bin/env bash
set -e
go mod tidy # <-- non 0 return code
echo 'we never get here' |
That makes sense. How about maybe make it optional? e.g. when it's executed with a flag it should return non-zero when it made any changes. |
@gopherbot, please add label modules |
go mod tidy
should return non-zero when it made changes to go.mod and/or go.sum files
We could think about adding a flag that means "don't do the update, but fail if one is needed". |
- 'go mod verify' is not that useful and isn't equivalent to govendor status. - 'go mod tidy -v' does not return non-zero exit code when dependencies aren't tidy - We might add 'go mod tidy -check' at some point, when it becomes a thing. See golang/go#27005 Until then it's better to keep provider setup aligned though.
When this is implemented, we should run this on the TryBots (#31640). Ideally |
This is a feature that we would like to see for our CI environment as well (we want to verify that I echo the sentiment expressed by @jayconrod that it would be ideal if this check could be performed without network access -- is it feasible for the |
It's would be useful to reduce git conflict in lint scenario |
Networkless operation is a nice to have. Dry-run flags and intuitive exit codes are perhaps a more immediate concern. |
This sounds to me like the solution that is most similar to how other tools solve this problem. It'd be good to surface an exit code mode consistently across all the Go tool commands that we routinely use as checks in CI pipelines. Today running checks for go mod, go fmt, and golint all use unique and unintuitive patterns: OUTPUT=$(gofmt -d .)
if [[ $OUTPUT ]]; then
exit 1
fi
golint -set_exit_status
go mod tidy
git diff --exit-code -- go.mod go.sum We could reuse the pattern demonstrated by golint: golint -set_exit_status
go fmt -set_exit_status
go mod tidy -set_exit_status Or, we could take the opportunity to use a term that is used by other tools, like golint -exit-code
go fmt -exit-code
go mod tidy -exit-code |
@bcmills This has a 1.18 milestone; is it likely to happen for 1.18? Thanks. |
@bcmills The issue is added to the G1.19 milestone; Is it likely to happen for 1.19? Thanks |
@samthanawalla, this should be a fairly straightforward feature to implement, and would be useful for CI tooling. (This was in the NeedsDecision state pending a final decision about what the command-line flag should be named; @matloob and @rsc may have some thoughts on that.) |
Change https://go.dev/cl/579055 mentions this issue: |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.11rc1 darwin/amd64
Does this issue reproduce with the latest release?
N/A
What operating system and processor architecture are you using (
go env
)?What did you do?
go.mod
andgo.sum
filesgo mod tidy
to add them backWhat did you expect to see?
go mod tidy
should return non-zero as it made changes. This way it could be integrated to tools like pre-commit hooks to make sure that we don't commit untidiedgo.mod
andgo.sum
files into version controlWhat did you see instead?
go mod tidy
returned zeroThe text was updated successfully, but these errors were encountered: