I have a setup in which the service created by my bitbucket pipelines is deployed on a machine which is not publicly accessible. It is deployed through a pull based mechanism in which a daemon periodically checks for the new versions of the service and runs them. I want to link the pipelines with the success/failure of running this service i.e. if the daemon fails to run the service, it should somehow also fail the pipeline. Is this possible through any means?
I checked the pipelines API https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/pipelines
And the only capability it provides me is to stop a running pipeline which doesn't fulfill my use case
generally a pipeline fails when any of the commands run in that step exits with non zero exit code.
Is there a way for you to check in the pipeline step that the service daemon failed and exit 1? Or what exactly is happening in the pipeline when the daemon deploys stuff? is it somehow waiting for it to finish? or it is more or a fire-and-forget process and you want to change the result of a pipeline ex post after it actually finished?
It's the last one. The pipeline simply publishes the artifacts somewhere and ends. The daemon is running independently and it pulls the artifacts and deploys them on a certain cluster. Ideally I'd want to link the two. I want that the pipeline shouldn't end until the daemon process completes and reports to the pipeline whether the deployment has failed but I can't link the two directly as the daemon process is running inside a private network.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Theoretically one option would be to have a manual step triggered from outside after the daemon process completes. In that manual step one would query the deployment and pass/fail based on the result. However AFAIK there is no public API to trigger a manual step.
Also the pipeline would appear green even if the manual step was never triggered so the level of trust there is suboptimal. Ideally we would keep such pipeline in 'running' state until the callback from outside appears or timeouts.
In any case it's not a feature that is currently supported by pipelines as far as I can tell.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.