Bitbucket Pipelines (legacy)
AI-generated content
This document was generated by an AI assistant. Verify accuracy before relying on the details.
Before the monorepo conversion, each adb-* repo had its own bitbucket-pipelines.yml that built a Docker image, pushed to Docker Hub, and (for adb-charts) ran terraform apply to deploy to AKS. After the submodule → monorepo conversion, those YAML files are still in each subdirectory but CI has moved to GitHub Actions (.github/workflows/). The Bitbucket files are kept for historical reference only.
At a glance
| Fact | Value |
|---|---|
| Status | superseded by GitHub Actions on 2026-05-02 |
| Files still in repo | */bitbucket-pipelines.yml in each subproject |
| What still runs on Bitbucket | nothing — the org's Bitbucket Pipelines are not connected to the GitHub monorepo |
| Replacement | .github/workflows/{ci,deploy-staging,deploy-production,pr-deploy,pr-destroy,nightly-cleanup}.yml (PR #3 series) |
Details
The legacy pipelines used:
- A
pipelineIAM user (still exists in AWS — see Current AWS state) for ECR-style pushes (although they actually push to Docker Hub). - A custom
start-up/shut-downset of pipeline triggers for the dev AKS clusters, used to stop/start non-prod clusters off-hours for cost. - Per-env Terraform workspaces in
s3://tf-states.life-connect.fr/envs/<env>(28 of them; see Terraform-managed envs (legacy)).
Sunset plan
- Once the new
infra/Pulumi project is live for staging + production, archive thebitbucket-pipelines.ymlfiles (don't delete — they document historical behaviour). - Decommission the
pipelineIAM user once nothing reads it. - Migrate the
start-up/shut-downcost-saving cron to a GitHub Action or AWS scheduled Lambda once we know the ECS Fargate cost profile (Spot capacity might make this unnecessary).
Open questions
- Are any external systems (Bitbucket webhooks, deploy targets) still pointing at the old repos? Worth a sweep before we delete the YAMLs.