Skip to content
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

Provide a way to ignore error exit codes #408

Open
Anonymous-Coward opened this issue Jul 17, 2023 · 1 comment
Open

Provide a way to ignore error exit codes #408

Anonymous-Coward opened this issue Jul 17, 2023 · 1 comment

Comments

@Anonymous-Coward
Copy link

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.

Anonymous-Coward pushed a commit to Anonymous-Coward/git-resource that referenced this issue Jul 20, 2023
Provides an implementation of the feature requested in
concourse#408.

Signed-off-by: Anonymous-Coward <[email protected]>
Anonymous-Coward pushed a commit to Anonymous-Coward/git-resource that referenced this issue Jul 20, 2023
Provides an implementation of the feature requested in
concourse#408.

Signed-off-by: Anonymous-Coward <[email protected]>
Signed-off-by: fjurcov <[email protected]>
@taylorsilva
Copy link
Member

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants