How to enforce centralized pipeline validation and prevent child repo merges to develop/any branch?

vinoth_vinothkumaar_accenture

We’re planning to use a centralized CI/CD pipeline architecture in Bitbucket, where:

Each child repository has a minimal bitbucket-pipelines.yml file.

The child pipeline triggers a centralized pipeline (in a separate repo) using the Bitbucket API for develop, release, and master branches.

The centralized pipeline performs all actual validations (SonarQube, Veracode, security scans, Docker build, deployments, etc.) and reports the results back.

Our problem
When developers raise a pull request — for example:
feature/* → develop

The child repo’s PR pipeline executes.

That PR pipeline currently just exits successfully (exit 0) because PR scans are handled centrally.

Therefore, Bitbucket marks the PR build as “successful”,
even though the centralized pipeline never ran (since it only triggers for branch builds, not PRs).

Because of this, the PR can be merged into develop without any centralized validation happening.

So, even if we use “Require a successful build” in branch restrictions,
Bitbucket still considers the child pipeline success as valid — and allows merging.

What we want to achieve
We want to block merges to protected branches (like develop) unless:

The centralized pipeline has been triggered for that commit, and

It has completed successfully (posting a SUCCESSFUL build status back to the commit).

In other words, we need Bitbucket to:

Ignore or reject child repo builds for branch protection checks, and

Require a specific build status (e.g. CENTRAL_VALIDATION) that can only be set by the centralized pipeline.

What we’ve tried
Enabled “Require a successful build” under branch restrictions for develop.
→ Works, but counts any successful build (including the child repo’s PR pipeline exit 0).

Considered adding a custom build status key (CENTRAL_VALIDATION) via API from the centralized pipeline.
→ Works only if the centralized pipeline runs, but if the child repo never triggers it, Bitbucket doesn’t block merges.

We can’t fully protect or remove the child pipeline YAML since developers initialize and maintain those repos.

Our ask
Is there a way in Bitbucket Cloud to:

Enforce that a specific build key (e.g. CENTRAL_VALIDATION) must exist and be successful before allowing merges?

Or block merges when no centralized validation status exists at all for that commit?

Any best practices or upcoming features to better support centralized pipeline control would be greatly appreciated.

Saxea _Flowie_

Hi @vinoth_vinothkumaar_accenture ,

Enforce that a specific build key (e.g. CENTRAL_VALIDATION) must exist and be successful before allowing merges?

Not possible to enforce specific build key using the built-in checks, but you could build an app with a custom merge check for it.

Alternatively, you could use an existing app like Flowie, which we provide, that has support for it.

Having said that, from what you described, wouldn't setting the minimum builds to two be enough? That way, it would require the local and central build in order to pass the check?

If you really need to enforce the key - say for instance, the child repo can have more than one local pipeline build, then you could use Flowie with a custom function, to validate your builds and ensure the central validation key is always present.

Any best practices or upcoming features to better support centralized pipeline control would be greatly appreciated.

In terms of best practices, I would suggest not relaying on the child pipelines to trigger the check, as you would need to be able to enforce that is in place. e.g. ensure that someone didn't disable it accidentally, or disabled it temporarily and forgot to renable it, when editing the pipelines.yaml. It depends on much you need to enforce, from compliance perpective this is likely going to be an issue.

To solve this, you could have your own webhook that triggers the central build, or use an app like Flowie that lets you automate and enforce it using smart pipelines, for instance. This would allow you to set this at workspace level, and be enabled automatically as soon as the repo is created.