You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The most convenient way to check in a script the result of a command or another shell script is to check its exit code. However checking in a script (eg. in a CI job) that the formatting of source files is correct requires a bit of scripting with gofmt. In particular, a one-liner is not very readable as demonstrated below.
(granted that my CI job fails if the command returns an error code != 0, and fails otherwise)
To simplify such a use case, I propose to add a flag to the gofmt: -x which exits the program with an error code != 0 iff there were any files that were modified (or any file that must be modified in case the program is dry-run with -l).
On the implementation itself, there are two things that could be discussed IMO:
the program returns an error code 2; returning anything else would complicate the implementation as an error during the formatting (eg. permissions insufficient) also returns 2. However I think it's safe to assume nobody want to differentiate between errors and wrongly formatted source code.
the -x flag name is maybe not the best choice, I chose it because of e[x]it and both [e]xit and [r]eturn code are taken.
The text was updated successfully, but these errors were encountered:
The most convenient way to check in a script the result of a command or another shell script is to check its exit code. However checking in a script (eg. in a CI job) that the formatting of source files is correct requires a bit of scripting with
gofmt
. In particular, a one-liner is not very readable as demonstrated below.As an example, here's what I do on my CI job:
(granted that my CI job fails if the command returns an error code != 0, and fails otherwise)
To simplify such a use case, I propose to add a flag to the
gofmt
:-x
which exits the program with an error code != 0 iff there were any files that were modified (or any file that must be modified in case the program is dry-run with-l
).I proposed an implementation on https://go-review.googlesource.com/c/go/+/316930 that was -2 because its an API change, hence this proposal.
On the implementation itself, there are two things that could be discussed IMO:
2
; returning anything else would complicate the implementation as an error during the formatting (eg. permissions insufficient) also returns2
. However I think it's safe to assume nobody want to differentiate between errors and wrongly formatted source code.-x
flag name is maybe not the best choice, I chose it because ofe[x]it
and both[e]xit
and[r]eturn code
are taken.The text was updated successfully, but these errors were encountered: