Skip to content

feat: Bitbucket module-CI (shared core + Bitbucket glue) - #21

Open
SatyendraGollaFacets wants to merge 1 commit into
masterfrom
feat/bitbucket-module-ci
Open

SatyendraGollaFacets wants to merge 1 commit into
masterfrom
feat/bitbucket-module-ci

Conversation

@SatyendraGollaFacets

Copy link
Copy Markdown
Contributor

What

The Bitbucket counterpart of module-ci-action (GitHub, #17) and module-ci-gitlab (#20). Adds module-ci-bitbucket/run.sh — the thin Bitbucket glue that runs the same shared module-ci-core.sh the other two hosts run, so the three never drift.

Why a script, not an include

GitLab consumes its template as a remote include:. Bitbucket Pipelines has no remote include, so a modules repo's bitbucket-pipelines.yml can't pull a hosted template. It instead curls this run.sh (pinned to v1) and runs it. The glue resolves the mode, maps Bitbucket's predefined vars → the generic MC_* contract, fetches + runs the core, and posts the PR preview comment.

Mode Trigger Diff range
preview pull request merge-base(dest, HEAD)..HEAD
publish default-branch push HEAD~1..HEAD (squash-merge = 1 commit)

Scope

  • Preview + publish supported. Cleanup-on-close deferred — Bitbucket runs no pipeline on PR close; the core already implements cleanup, only the Bitbucket trigger is missing. Same gap GitLab has.

Testing

  • shellcheck clean.
  • Mode-mapping dry-run verified for both modes (preview → base..head via merge-base; publish → HEAD~1..HEAD).
  • Full pipeline execution runs on real Bitbucket runners against a reachable control plane — same as the GitLab robot, validated there against an internet-reachable CP.

Follow-up

After merge, move the v1 tag so …/github-actions/v1/module-ci-bitbucket/run.sh resolves — then the control-plane wire PR works. (Same release step the GitLab robot needed.)

🤖 Generated with Claude Code

The Bitbucket counterpart of module-ci-action (GitHub) and module-ci-gitlab.
module-ci-bitbucket/run.sh is the thin Bitbucket glue: it resolves the mode,
maps Bitbucket's predefined variables to the generic MC_* contract, fetches and
runs the SAME shared module-ci-core.sh the other hosts run, and posts the PR
preview comment — so the three hosts never drift.

Bitbucket Pipelines has no remote include (unlike GitLab's `include: remote:`),
so a modules repo's bitbucket-pipelines.yml can't pull a hosted template; it
curls this run.sh (pinned to v1) and runs it. The control-plane wire PR flips the
bootstrap's placeholder bitbucket-pipelines.yml to do exactly that.

Preview (on PR) and publish (on default-branch push) are supported; cleanup-on-
close is deferred (Bitbucket runs no pipeline on PR close), the same gap GitLab
has. Mode-mapping dry-run verified for both modes; shellcheck clean.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants