Provide a way to ignore error exit codes

[Anonymous-Coward]

Is your feature request related to a problem? Please describe.

Concourse provides no way to store state between jobs, or pipelines, or even between job executions. Therefore, in order to keep track for versions being deployed to various places, we use a dedicated git repository, where deployment jobs push an update for each version update of an application or component they perform.

However, when you run the same job twice in a row, there's no version to do any update, if nothing has changed in the application or component being deployed by that job. With concourse providing no possibility of conditional execution either, the git push operation is therefore executed on all executions, even on those who don't do anything, causing the pipeline to fail, even if nothing went wrong.

Describe the solution you'd like

Add a parameter to the put/out operation corresponding to git's quiet parameter. That one suppresses git's non-zero exit code on empty pushes.

Describe alternatives you've considered

Scripting git in a task. This, however, would defeat the purpose of using the concourse git resource.

Additional context

The same problem can occur when a deployment pipeline is triggered but decides not to perform the deployment/upgrade, for example because it checks some quality gates or some external configuration and finds the conditions for an upgrade are unmet (for example if there's a long running test or other operation running on the target application/component, which would be disrupted or just rendered irrelevant by an interfering fresh deployment), for the version to be deployed. You don't always want a job to fail, in such a situation.

[taylorsilva]

I'm curious, do your downstream jobs depend on this resource passing the version from one job to the next? If not, would wrapping your put step in a try step work?

[taylorsilva]

I've come to realize I don't understand the use-case you're describing here. I've had jobs structured like this:

- get: repo
- task: potentially-modify-repo
- task: make-commit
- put: repo

repo is an input and output of both of the above task steps. This job passes in the following scenarios for me:

1. A change is made to files in repo, a new commit is made and pushed
2. No change is made in the first task step. The second task step makes no commit (the script checks for any changes). The put step also detects there is nothing to commit (says something like "Everything up-to-date") and succeeds.

I thought your issue here was the second one listed here, but from my personal experience, I now know that this is not the use-case.

I'm closing this issue since it's not understood what issue you're describing here and no one else in the community has chimed in with a similar problem. Feel free to update the issue with more details (reproducible steps). We can revisit this then.