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
I've been trying to use git_ops in one of my project's release pipeline, and I am surprised that when I push a chore commit (or something that should not create a version bump), the mix task completes with a status code of 1, therefore failing the workflow. Since there's no version to be determined, isn't that expected behaviour? Could we just log it instead and continue?
The text was updated successfully, but these errors were encountered:
Hello! Originally the design for this was for manual usage, so if you wanted to build a release but nothing would warrant a release, it should stop and tell you. I think there are valid scenarios for each (e.g if you want to push a new image, but only if a new release would happen, a non-zero exit status could be not what you want).
I'd be happy to accept a PR that adds a flag to get the behavior you're looking for though, because your use case makes perfect sense as well.
Right now we have a --yes to take out the interactiveness, so we could also have another to get this behavior. Unsure what the best name would be, but I'm open to ideas. The feature should be really easy to implement.
I can confirm that this is the expected behavior for my use case. I have a Gitlab CI pipeline that only allows prod deploys to be run once we have released our code, so if we don't have anything to ship (feats or fixes) we basically can't deploy to production. This forces the team to work with at least one fix or feat per release which actually ships value to our customers.
Hi,
I've been trying to use
git_ops
in one of my project's release pipeline, and I am surprised that when I push achore
commit (or something that should not create a version bump), the mix task completes with a status code of 1, therefore failing the workflow. Since there's no version to be determined, isn't that expected behaviour? Could we just log it instead and continue?The text was updated successfully, but these errors were encountered: