nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Pipeline with manual step shows as a successful build, but there are still pending steps

Daniel Ceregatti

I have a pipeline that sets up up environment variables in an artifact in the first step, which precedes a series of parallel steps which consume the artifact . I was not able to make this first step be manual due to a Bitbucket limitation, so I added a second step which adds `trigger: manual` to stop the pipeline before the parallel steps, this being the goal. Thing is, the first two steps flag the pipeline as a successful build, despite the icon being different, yet green. This new icon is a green filled circle within a circle outline. The success icon I had seen up to this point has been a checkbox in a circle. From the pipelines page:

Here is the pipeline itself, when in this limbo state:

At this point, the pipeline is considered built, and since we only require 1 successful build, the branch can be merged, but it should not be. I've changed the settings to enforce 2 builds, but the above is still only considered 1 build.

This pipeline is triggered from pull request submissions. The goal is to build pull request branches, but to have builds always happen manually.

Thoughts?

Accepted answers

All comments

Daniel Ceregatti

Cross posting: https://jira.atlassian.com/browse/BCLOUD-16689?error=login_required&error_description=Login+required&state=92def7a3-fe5b-4a1f-9a62-bc46cc65bda9

ktomk

The pipeline is considered a green build at a step that is to be manually triggered, which means, it did not break yet and it needs (manual) intervention [interactive pipeline]. This is only a perspective (possibility) which's true state is to be found out after user action (but so far it is green which is honestly correct by the Atlassian Bitbucket Pipelines Plugin).

Now you've run into the problem that your conceived user-action was to file a pull-request. And you need true state (not possibilities, e.g. a vague outcome).

So what to address here? That is hard to say. You write, there is only the requirement of one green build. The build is not yet finished, but green so far. And then you don't want to have a failing build on branch or tag (assuming git as VCS/SCM here) declarative.

So bringing together the state of the repository (revision) and build (build revision) you have an undecided outcome.

The only idea with the preconditions you formulate (at least one green build is OK) would be to forward to a deployment. This might cost you an integration branch, which means a merge represented as the deployment, therefore the merge button (the blue one) on a pull-request is only moving towards the extra branch. Depending on the branch model you follow, this will add an extra branch pre-master and post-develop (assuming you have a master -> develop -> topic (PR) -> develop -> master merge / commit cycle). Let's call the extra branch pre-master or integration.

So in terms of the Atlassian Bitbucket Pipelines Plugin, the branching model in Bitbucket must be set-up to merge any topic first of all into the pre-master / integration branch. That pipeline then needs to (re-)open a new PR (e.g. via git push and then the REST API) that allows for the manual merge button press and single build failure.

"Problem solved."

This is the only first-hand idea that comes to my mind. Yes, it sounds cumbersome / complicated. At least I'd say so, it's a purely technical solution.

To which problem actually?

Is there a problem of trust?

If so, be vigilant about PR pipelines. They only build green for the very moment they are filed, not later (and yes, later comes fast). Pull request pipelines do not suffice as quality gates (see ..., I wish I would have the bookmark at hand right now, nevertheless).

So the holy grail are branch pipelines. But they come after the pull-request has been merged.

Therefore having an integration branch allows more flexibility then. That branch can be develop btw. (if you still need master and develop instead of just considering in terms of releases that there is only one master branch in a decentralized repository like git or the likes). Sure that integration branch needs (code-) review before merge. Still then Atlassian Bitbucket is very lax on merge reviews which is by intention from Atlassian (at least that is how I understand the plenty since years talks they are publishing on platforms like Youtube, but I am not affiliated with Atlassian, so this is only my personal assumption which can never be as correct nor as good as a detailed, weighted, contextualized statement from the vendor itself [if they even can establish and afford such a precise form of communication at all, I can not at all for sure, so you (only) get exemplary opinions of mine]).

Which boils down to the question, do you have a problem of trust? From what I've learned is that it's very progressive to do conflict resolution late (in distributed systems). Sure that can lead you to a broken release or two, but then, it's still better even to just release early, often, small. This is normally what get's you the traction, ongoing. Embrace failure (fail more often, but don't repeat the same failure only to fail more often).

Alternatively require all builds to pass green. For ttat store for the revision a flag globally (e.g. S3 or whatever comes to your mind, the internet normally suffices) and make the second build (e.g. the branch build of the branch pushed to create the PR) fail unless the manual step of the pull request build has been proceeded (opting to make the build red instead of green at the manual step, you don't need a manual trigger there, Atlassian Bitbucket Pipelines Plugin offers the user-interface (UI) to re-run from a failed step, too and out of the box, just make a pipeline step fail).

Also with that, instead of S3 or the internet-s, push a tag on the revision, so you've even kept the state of acceptance (manual button pressed and rest of build green, too) inside the VCS/SCM repository. And here the benefit: Atlassian Bitbucket Pipelines Plugin supports triggers on new tags. So that new tag might offer the deployment options then. This spares another branch (the besait pre-master or integration) as actually you only want to have supervised revisions for deployments.

Merge back releases into develop (still guessing that is your branching model) and consider to have a strategy/keep in mind that supports/to support your practice of hot-fixing releases that have already been published / rolled-out so you don't have to click too much to get things into order as failure is part of the running business.

All in all, Atlassian Bitbucket Pipelines Plugin provides a nicely reduced experience for CI/CD which results in a plethora of options (which basically means it's pretty usable). I would not consider the fact that the first step of a pipeline run can not be manual a "limitation" as you coined it. The first step is just to be executed, period. Everything else would not make any sense in (semi-) automated processes like continuous integration or deployments (CI/CD) [IMHO]. If you don't want to run a pipeline, don't push the commit, keep it local. And run the build local until you know it suffices the requirements for publishing. At least then it's easier with distributed automation and fast results. And it also scales better in a team, very small or biggy-big.

And also consider if this is really a technical issue or the problem is more about how you interact in the team/the team interacts. Technology will not solve such kind of problems. A CI/CD pipeline should assist the work. Part of the work is that you can trust each other. And that is per every release of the software to production.

From what I've experienced, the easiest form to improve that is to shorten release cycles and to deploy more often. Not to count how many "continue" buttons have been pressed in between and by whom.

Embrace failure. Understand that if you can't roll-back a release just at ease, you've got a far bigger problem, CI/CD has not been designed specifically for roll-backs, but for rolling-on. Rollbacks you've to do your own.

The green state of a build is only temporary, even if we aim for it constantly.

Daniel Ceregatti

No matter how this is spun, I still can't agree that a partial pipeline should be able to satisfy a build requirement. It's just wrong.

ktomk

That's not what I wanted to trick you in.

The green build is only until to the state of next interaction. You can easily circumvent that to not have a manual trigger in there.

Let it fail early and you don't have these kind of problems. As I wrote in the prolonged answer, the Atlassian Bitbucket Pipelines Plugin offers similar interactivity on red builds as it does on green builds (if I remember correctly even before the green interaction was available). Just do not use manual triggers, make it fail right ahead until yours beloved preconditions are being sufficed.

Eitan Nargassi

Did you manage to find a workaround solution?

Only way I think is using bitbucket api to close the pull request as a final stage, but I hope it won't be neccesery

ktomk

If you close the pull request via the api as a final stage, I'd say it wouldn't make sense to add `trigger: manual` in the first place.

ramona niederhausern

Have you received an answer for this?

Github actions show a clearly - Success, but pending next action in their actions.

Bitbucket desperately needs this.. When looking at a pipeline I should easily be able to see if it Completed all steps successfully, or has Completed the last step, but pending any manual trigger/deploys

surprised this hasn't been addressed yet.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket-pipelines