Open pere3 opened 4 years ago
jannfis
commented
4 years ago That probably applies to most of the CLI commands. But I agree with you, we should have different (documented) exit codes for different exit scenarios, and thus making automation using the CLI much more practical.
pere3
commented
4 years ago Thanks, we also believe that valid diff output shouldn't be followed with a non-zero exit code, like it happens in helm-diff plugin (https://github.com/databus23/helm-diff).
Because diffs are usually a normal thing, but non-zero exit code is not. And it is an CI/CD job to determine this diff impact and validity.
jannfis
commented
4 years ago It's hard to tell what exit code is right. Following semantics of classical UNIX diff tool, the exit code is 1as well when the compared data differs. However, git diff returns exit code 0 regardless of differences or not.
Personally, I believe for automation it might be beneficial if different exit codes are used on different results of the operation, i.e. whether there have been differences or not. This allows for simple conditionals in shell, such as
if diff foo bar; then
# there were no differences
else
# there were differences if $? is 1, otherwise an error
fiI think we should not change the semantics of the exit code for when there is a difference or not. But I agree, that we should use other exit codes for failures, such as API server not reachable, application does not exist, etc.
pere3
commented
4 years ago Thanks a lot, i kinda forgot how unix diff operates - it really gives you a 1, if there is any difference between files (it works with binaries too!).
Will wait for other exit codes on failures implementation, any approx. ETA on that?
jannfis
commented
4 years ago Sorry, can't give you an ETA. The issue queue is quite full at the moment, but maybe a volunteer will step forward? :)
spirosoik
commented
3 years ago I can give it a try
ameytotawar
commented
1 year ago I am working on this issue.
OmerKahani
commented
1 year ago Looking at the code, in most cases an error will lead to exit code 20
But there are two commands that will use exit code 1 inside the command:
headless.NewClientOrDie & clientset.NewApplicationClientOrDie
The commands uses log.Fatal & log.Fatalf which will use exit code 1
As both of the commands are widely used, changing them will result in a breaking change.
The other option is to change the exit code used to signal there is a diff, which currently is set to 1, but that is also a breaking change :(
eugene70
commented
1 week ago I analyzed this issue. I think it would be better to allow specifying a code as an option rather than returning a fixed code.
There is also a similar option called --exit-code, which is a boolean value that returns an error code of 1 if true, and 0 if false. The default is true.
if foundDiffs && exitCode {
os.Exit(1)
}For compatibility reasons, this option will probably have to remain.
I think a new option would be something like --diff-exit-code or --exit-code-when-diff.
Checklist:
argocd version.Describe the bug
We are trying to use argocd diff output to determine situations, where next deployment will actually delete something inside out k8s cluster, rather than update or add.
When using argocd app diff command, exit code is always the same for actual "found diff" and "Failed to establish connection" cases.
To Reproduce
Expected behavior
We expect that argocd will throw different exit signals on failures (connection error), or at least an ability to correct it's behaviour with flags and parameters.
Same exit code values makes it impossible to distinguish actual command result inside jenkins pipeline.
Version