-
Notifications
You must be signed in to change notification settings - Fork 65
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
Feature request: flag to return return a failure exit code #474
Comments
This also makes it more difficult to run in a CI context, where a failure should indicate to the CI system that the operation was not successful. That's usually signaled with the exit code |
This is a good idea. However, the option would also have to define what the user defines as an error. Some things that could be considered an error:
Not all of these might be considered an error by all users. |
I would keep it simple and just deal with execution errors of any kind. I think that covers the vast majority of use cases. You'll get lost in the weeds otherwise. I don't think skips, no changes should be considered for this. Things like no change could be dealt with in the script by detecting it and throwing an error if people really want that behavior. If you felt it was really necessary to get so granular you could start with a flag for execution errors and build on with more flags later for the other scenarios? |
Hmm, I reviewed both comments and didn't see a specific mention about skipping. I think your point is a good one, it seems like a separate issue though that would be handled by additional flags or redesign of existing flags such as |
From my point of view, it makes sense to error in cases where doing the same operation by hand in a shell would have a non-zero exit code (even though this tool may not be using any CLIs directly). After all, kind of the point of So to me, that includes everything in your list
|
Thanks for the discussion and sorry if I'm misunderstanding, it sounds like you are saying all of those would be part of this new feature? I agree on script failure and git push/pull failure.
Aren't you already dealing with this via
The use case for adding exit codes would primarily be for automated execution, in our case we're using the tool to do nodejs package updates weekly across 50+ repositories. Executions that result in no changes are not an error, it just means that no updates were found. If you make no changes result in an error then we are no better off than we were before and would get no benefit out of this new feature. I suspect that this would be the case for many who would use this feature. I think again if this behavior is desired (fail on empty changes) it needs to be a separate flag and unrelated to the feature request here. |
Some of it is up for interpretation I think. I'm just trying to give a backing theory for how to design the exit codes For Normally, if you use plain The issue I want to address with branches is when there are many developers altering the same GitOps repos. If you're modifying 50 or 100 repos, and 1 is skipped because someone else has already created the named branch, it's likely that you will miss this happened unless you're carefully observing the output. In cases like this, an exit code is a single, unifying signal that tells the user they need to carefully read the logs and take some action. Otherwise the user needs to know the specific content of log messages, use things like grep, and so on -- a more brittle method of error detection |
The feature request
flag to return return a failure exit code if any repo(s) do not succeed.
apologies if I missed that this is currently available somewhere, did not see it.
My use case
Would like to use multi-gitter with some cron jobs for package updating and would like a clean way of notifying when it fails on a repo.
Implementation
The text was updated successfully, but these errors were encountered: