TechPrufer
Get started
Atlassian
Atlassian logoAtlassian · Feature trail

Bitbucket Pipelines Runner

95 posts · Nov 2015 – Aug 2026

What this trail covers

Bitbucket Cloud's CI/CD capabilities are enhanced with a migration tool for Bamboo, supporting build plans, deployment projects, and custom plugins. The tool automates the transition to Bitbucket Pipelines, offering zero wait times, reduced operational overhead, lower costs, and effortless compliance. New features include deployment plan migration, support for custom transformers (Python scripts for mapping plugins to Pipes or shell commands), instance-level migration for entire Bamboo instances. The platform is evolving its runner model to offer a free tier with up to 100 basic runners per workspace and an optional paid Premium runners tier for advanced orchestration, higher limits, and premium support. The billing model for premium runners is shifting to a usage-based approach reflecting maximum concurrent build slots actually used per month. Premium runners will unlock features like dedicated support, pluggable storage, increased runner limits (up to 1,000 per workspace), runner management APIs, runner groups, disabling cloud runners, ephemeral macOS runners, auto-update, and advanced queue management.

All Atlassian trails
  1. Introducing the redesigned deployments experienceThis post introduces a redesigned Bitbucket Pipelines Deployments page. Key improvements include a cleaner, column-based layout for environments, enhanced filtering capabilities, richer deployment cards displaying essential information (status, environment name, build number, commit details, time), easily accessible deployment history panels, and live, real-time updates as pipelines execute. It also provides a sample `bitbucket-pipelines.yml` for teams new to Bitbucket Deployments.
  2. Custom deployment permissions for your environments (Beta)Introduces custom deployment permissions for Bitbucket Pipelines environments, allowing granular control over who can trigger deployments. This feature enables gating specific environments to authorized users and groups, reducing production risk, avoiding unnecessary admin access, and supporting compliance workflows by separating code merge and deployment responsibilities. Permissions are managed via Repository settings → Pipelines → Deployments, with limitations on the number of users/groups per environment and precedence over scheduled/automated deployments.
  3. Bamboo to Bitbucket Pipelines migration tool is now GAThis post announces the General Availability (GA) of the Bamboo to Bitbucket Pipelines migration tool. Key new features include the migration of Bamboo Deployment Projects into Bitbucket Pipelines custom pipelines, support for custom Python scripts to map third-party or custom plugins into Bitbucket Pipes or shell commands, instance-level migration for entire Bamboo instances, and improved audit reporting that surfaces plugin keys for unsupported tasks.
  4. Introducing Package triggers in Bitbucket PipelinesIntroduces a new `package-artifact-created` trigger for Bitbucket Pipelines. This trigger allows custom pipelines to be automatically run when a package artifact is created in Bitbucket Packages. It enables automation of post-publish workflows like validation, scanning, promotion, and notifications. The trigger provides package-specific variables (`BITBUCKET_TRIGGER_PACKAGES_PACKAGE_TYPE`, `BITBUCKET_TRIGGER_PACKAGES_PACKAGE_NAME`, `BITBUCKET_TRIGGER_PACKAGES_ARTIFACT_NAME`) for use in conditions and scripts. The post also details limitations on trigger conditions, pipeline initiation, and preventing infinite loops with other trigger types.
  5. Track Deployment status for your PRs (Beta)Introduces the Beta version of Deployment Status Tracking for Pull Requests, which surfaces live deployment statuses directly within the PR list view. This feature maps deployment status to the exact commit executed, providing immediate visibility into where code is deployed across environments. It includes a dedicated Deployment column on the PR list view, smart environment breakdowns (up to 10 environments), and dynamic environment renaming. Technical constraints include tracking status only for the head commit of a PR, displaying statuses for deployments within the last 6 months, and a maximum of 10 environments per status.
  7. Premium self-hosted runners are generally availableIntroduces Premium self-hosted runners for Bitbucket Pipelines, offering enhanced capabilities over the free tier. Premium runners provide premium support, custom storage, custom volumes for Docker-based runners, custom resources for Docker-based runners, advanced queue management, runner groups (coming soon), and auto-update (coming soon). Pricing is $15/month per concurrent build slot, with two slots included in the Premium plan. The post also clarifies billing based on actual concurrent usage and outlines requirements for accessing premium runners, including connection to an Atlassian organization for billing.
  8. Introducing on-demand Pipelines: run pipelines via APIIntroduces 'on-demand pipelines' which allow programmatic generation and execution of pipeline definitions via the Bitbucket Pipelines API. This enables dynamic pipeline creation based on context (e.g., services, environments, tests) without committing YAML to a repository. Supports triggering via API requests with YAML in the body, targeting branches or commits, and passing variables. Security is enforced by requiring write access to the target branch. Use cases include ad-hoc quality gates, safe experimentation, event-driven automation, and dynamic workflows.
  9. Share artifacts between parent and child pipelinesIntroduces the ability to share artifacts between parent and child pipelines in Bitbucket Pipelines. This allows for greater coordination and modular processing of larger operations by enabling uploads from parent to child and downloads from child back to parent. The configuration is done via an `artifacts` section within the `pipeline` steps, specifying `upload` and `download` lists.
  10. Introducing Agentic Pipelines: AI automation for chores devs don’t want to doIntroduces 'Agentic Pipelines' which extends Bitbucket Pipelines beyond CI/CD to automate manual, tedious, and repetitive tasks using AI agents. Demonstrates an example of an agent that automatically updates repository READMEs by examining code changes and raising pull requests. Provides five additional examples: automatically identifying and fixing security vulnerabilities, cleaning up feature flags, generating release notes, generating PR summaries, and ensuring quality test coverage. Highlights the use of Rovo Dev AI agent and the need for specific scopes for pipeline execution.
  11. Introducing: Final Steps in Bitbucket PipelinesIntroduces 'final steps' to Bitbucket Pipelines, a new construct that guarantees execution of a designated step after all other steps in a pipeline have completed, regardless of their success or failure. This is achieved by adding a `final:` section to the `bitbucket-pipelines.yml` configuration. The post outlines usage examples, restrictions (e.g., only one final step, must be last, no grouping/parallelization, no child pipeline triggering, no manual/deployment/fail-fast options), and emphasizes its utility for cleanup, telemetry, notifications, and audit events.
  12. Introducing the Bamboo to Bitbucket Pipelines migration tool (Beta)This post introduces a beta migration tool for Bamboo to Bitbucket Pipelines. The tool includes an audit command for readiness reports, a forecast command for cost prediction, and a migrate command for automatic translation of Bamboo plans to Bitbucket Pipelines syntax. The tool is open-source and extensible for custom plugins. It aims to reduce operational overhead, costs, and migration complexity for teams moving from Bamboo Data Center to Bitbucket Pipelines.
  13. Announcing the Next Chapter for Bitbucket Pipelines RunnersThis post announces a new operating model for Bitbucket Pipelines runners, introducing a free tier with up to 100 basic runners and an optional paid Premium runners tier. The billing for premium runners will change from a per-concurrent-build-per-month model to a usage-based model reflecting maximum concurrent build slots actually used. It details migration scenarios for existing users of v3 and v5 runners, outlining how workspaces will be transitioned to either free or premium runner functionality based on their current setup. Premium runner features are expanded to include premium support, pluggable storage, increased runner limits, runner management APIs, runner groups, disabling cloud runners, ephemeral macOS runners, auto-update, and advanced queue management. A new runner version (v5) will be released on June 3, 2026, which will be the upgrade path for both free and premium runners.
  14. OpenTelemetry traces for Bitbucket Pipelines via webhooksThis post introduces the emission of OpenTelemetry (OTel) traces for Bitbucket Pipelines via webhook events. It details the span model (pipeline run, step, command, container attributes) and how to consume these traces in an observability stack. The contribution enables users to gain deeper insights into pipeline performance, reliability, and resource utilization by correlating pipeline execution with other system traces.
  15. Split your pipelines workflows across multiple filesIntroduces the ability to split Bitbucket Pipelines definitions into multiple YAML files within a repository, improving modularity, reusability, and maintainability of CI/CD configurations. This feature allows for defining pipelines in separate files (e.g., `.bitbucket/shared-pipelines.yml`) and importing them into the main `bitbucket-pipelines.yml` file. It also enables exporting shared pipelines for use across different repositories within the same workspace.
  16. Power up your pipeline workflow with 24x and 32x step sizesThis post introduces larger build size options (24x and 32x) for Bitbucket Pipelines runners, offering increased CPU and memory (48 CPU/96GB for 24x, 64 CPU/128GB for 32x) compared to the existing 16x builds (16 CPU/32GB). It provides examples of how to specify these sizes at the pipeline or step level.
  17. Announcing powerful upgrades & a new pricing model for self-hosted runnersThis post announces Bitbucket Pipelines self-hosted runners V5, introducing Docker volume mounts for persistent storage between steps/builds, customizable CPU/memory allocation per step, and integration with S3/Google Cloud Storage for private cloud data storage. It also details a new paid licensing model based on concurrent build slots, with pricing and transition timelines. Future features like ephemeral macOS runners are mentioned.
  18. Introducing Dynamic Step Condition for Bitbucket PipelinesIntroduces a new `state` condition type for Bitbucket Pipelines steps, allowing dynamic skipping of steps based on boolean expressions evaluated using pipeline context variables. This enables more intelligent and flexible CI/CD workflows by leveraging workspace, repository, deployment, and output variables. The post details how to use this feature with examples for blocking deployments during incidents and skipping deployments with critical vulnerabilities, and also explains how to combine `state` conditions with existing `changesets` conditions. It outlines supported expression syntax, variable types, and troubleshooting mechanisms.
  19. Upgrades to Pipelines Artifacts: New Artifact Types & Selective DownloadIntroduced new artifact types: 'shared' for cross-step data sharing and 'scoped' for step-specific files (logs, reports, screenshots). Implemented selective artifact download, allowing users to specify which artifacts to download in a step (`download: true`, `download: false`, or a list of artifact names). Added `capture-on: failed` for scoped artifacts. Enhanced artifact organization by allowing multiple glob patterns per artifact and specifying ignore patterns and search depth. Updated self-hosted runner version requirement to v3.31.0.
  20. Reimagining how you structure workflows in Bitbucket PipelinesThis post introduces a new top-level `triggers` property and `condition` blocks within Bitbucket Pipelines YAML. It enables event-driven pipeline execution with complex logical expressions and glob functions for conditions, supporting parallel fan-out of multiple custom pipelines. It also details how pull request pipelines can now trigger based on the destination branch and provides separate build statuses for each pipeline run. The post contrasts this new model with traditional selectors and provides an example configuration.
  21. Unlocking workflow flexibility with variable-sharing between parent and child pipelinesIntroduces the ability to pass variables from parent pipeline steps to child pipelines using the `input-variables` section in the parent step's YAML configuration. This allows for dynamic configuration and data sharing between orchestrated pipeline stages, with support for static values, repository variables, and workspace variables. Includes limitations on security (not for secrets), a maximum of 20 input variables, and validation rules for variable keys and values.
  22. Why Jenkins might cost you 10x more than Bitbucket PipelinesThis post analyzes the total cost of ownership (TCO) for self-hosted CI/CD solutions like Jenkins compared to SaaS offerings like Bitbucket Pipelines. It details the hidden costs of self-hosting, including developer productivity sacrifices due to under-provisioning, wasted compute from over-provisioning, and the significant expense of maintaining a dedicated platform engineering team for auto-scaling. The analysis quantifies these costs using a hypothetical 500-developer team, demonstrating that Bitbucket Pipelines is significantly more cost-effective due to its elastic scaling and pay-as-you-go model, which eliminates the need for internal infrastructure maintenance teams.
  23. Unlocking insights: Introducing Step Metrics for Bitbucket PipelinesIntroduces step metrics for Bitbucket Pipelines, providing visibility into CPU and memory usage for build and service containers within pipeline steps. Metrics are collected every 5 seconds and retained for 14 days, becoming available only after a step completes. This allows users to spot bottlenecks, optimize resource allocation, and troubleshoot issues with data-driven confidence.
  24. 1 Billion Build Minutes Later: How we reinvented CI/CD at AtlassianThis post details Atlassian's strategic decision and execution to consolidate its entire CI/CD landscape onto Bitbucket Pipelines, migrating from fragmented solutions like Jenkins and Bamboo. It outlines the key requirements for scaling CI/CD to over 9,000 users, including enterprise-grade scale, reliability, flexibility, centralized structure, extensibility, and future-proofing for AI. The post quantifies the impact of this migration, reporting significant reductions in pipeline build time (75%), lead time (96%), and recovery time (65%), alongside increased deployment frequency and developer satisfaction. It highlights specific enhancements like autoscaling runners, scheduled pipelines, parallel pipelines, and dynamic pipelines, and introduces AI features like Pipeline Troubleshooter and Deployment Summarizer.
  25. To Bitbucket from Jenkins: Enhancing Developer ExperienceThis post contrasts the self-hosted Jenkins CI/CD experience with Bitbucket Pipelines, highlighting the inefficiencies and operational overhead of managing Jenkins (EC2 setup, plugin management, Groovy scripting, emergent work from infrastructure compliance and availability concerns). It emphasizes how Bitbucket Pipelines, particularly with features like Dynamic Pipelines, offers a more integrated, cloud-native, and developer-experience-focused solution by reducing manual configuration, improving consistency, and offloading infrastructure management. The post also mentions the use of Rovo Dev CLI as an AI tool to assist in writing Jenkinsfiles and updating Jira issues, further enhancing developer productivity.
  26. Introducing parent/child pipelinesIntroduces parent/child pipelines for Bitbucket Pipelines, allowing a step in one pipeline to trigger and encapsulate another custom pipeline. This enables greater parallelism, modularity, and seamless reruns, addressing challenges with monolithic pipeline configurations and the 100-step limit. New step properties 'type: pipeline' and 'custom' are introduced. Limitations include child pipelines only supporting custom pipelines, no support for deployments/deployment stages in child pipelines, a maximum of 20 child pipeline steps per parent, and only one level of nesting.
  27. Evolving deployments in Bitbucket Pipelines: Concurrency Groups and EnvironmentsThis post introduces two new features for Bitbucket Pipelines: Concurrency Groups and Environments. Concurrency Groups replace restrictive deployment locks with a first-in-first-out queueing mechanism for steps within a group, allowing for more flexible and automated step concurrency management. Environments decouple environment variables and permissions controls from the full Deployments framework, enabling their reuse across parallel steps and without enforcing other deployment-related features. The post also details how to combine these new features with existing deployment tracking.
  28. New IP addresses for Bitbucket PipelinesThis post announces updated IP addresses for Bitbucket Pipelines build environments. It instructs users to update their firewalls, access lists, security groups, or other network policies to allow connections to the new address list to maintain performance and reliability.
  29. Enhancements to Bitbucket Pipelines step conditionsIntroduces the `excludePaths` capability for `changesets` conditions at both the `step` and `stage` levels within Bitbucket Pipelines. This allows users to define glob patterns for files that, if only changed, will cause the associated step or stage to be skipped, thereby reducing unnecessary pipeline executions and improving speed. Examples for both step-level and stage-level configuration are provided, along with a visual representation of skipped steps in the UI and a note on the limitation of not being able to use `excludePaths` and `includePaths` together.
  30. Introducing Runtime v3 – Multi-arch images and more control over DockerIntroduces Runtime v3 as an opt-in feature for Bitbucket Pipelines, allowing users to enable privileged containers, use the latest Docker CLI, leverage buildx for multi-arch builds and remote caching (e.g., S3), and bring their own Docker-in-Docker (DinD) images. This deprecates the previous automatic mounting of the Docker CLI and the built-in Docker cache, requiring users to ensure Docker CLI is present in their build image or installed via script, and to use Buildx caching instead.
  31. Use variables in any part of your Pipelines .yamlThis post introduces the ability to use variables (`${{MY_VARIABLE_KEY}}`) within any section of a Bitbucket Pipelines `.yaml` file, not just within `script` sections. This allows for parameterization of cache keys, artifact names, build images, and other workflow configurations, enhancing the flexibility and reusability of pipelines.
  32. Introducing the “retry” step failure strategy for Bitbucket PipelinesThis post introduces the `retry` step failure strategy for Bitbucket Pipelines, allowing automatic retries of failed steps up to a configurable maximum count (1-10). It also extends failure strategy support to the parent level of parallel groups and stages, enabling inherited strategies that can be overridden at the step level. The `retry` strategy is mutually exclusive with `fail-fast` and does not support deployment steps or stages. Visual updates in the Pipelines view now communicate retry attempts.
  33. Easily share data between steps in Bitbucket PipelinesIntroduces a new feature in Bitbucket Pipelines that allows environment variables to be defined in one step and accessed in subsequent steps within the same pipeline. This is achieved by writing variables to a specified path (`$BITBUCKET_PIPELINES_VARIABLES_PATH`) and declaring them in the `output-variables` section of the YAML. The post details considerations for variable naming (last write wins), security (not for secrets), limits (50 variables, 100kb total), parallel steps, and scope (pipeline lifetime).
  34. Announcing ARM builds in cloud for Bitbucket PipelinesIntroduces ARM build support for Bitbucket Pipelines cloud runtime, allowing users to select ARM architecture for their build steps via the `arch: arm` configuration in `bitbucket-pipelines.yml`. This requires explicitly declaring an ARM-compatible Docker image. The new runtime is powered by a new internal runtime that has been in use for over six months.
  35. Introducing step failure strategies in Bitbucket PipelinesThis post introduces the 'Step Failure Strategies' feature for Bitbucket Pipelines, specifically the 'ignore' strategy. It allows individual steps to fail without causing the entire pipeline to fail, enabling more granular control over CI/CD workflows. The post details the configuration using the `on-fail` option with a `strategy` property, provides a code example, and describes visual updates in the UI to indicate ignored failures. Limitations include non-support for deployment steps and the inability to rerun ignored failed steps.
  36. General availability of the Jenkins to Bitbucket Pipelines migration toolThis post announces the general availability of the Jenkins to Bitbucket Pipelines migration tool. Key updates include support for 12 additional plugins, mapping parallel stages in Jenkins to parallel steps in Bitbucket Pipelines, and support for plugins used in over 5% of Jenkins instances. The tool handles unsupported plugins by copying them to the outputted bitbucket-pipelines.yml in their original format, with clear markings for manual review. It also allows customers to write custom translation logic for their own custom functionality. The post provides access to the open-source repository and a step-by-step guide for migration.
  37. Quickly diagnose issues by viewing previous Pipeline runsThis post introduces a new capability within Bitbucket Pipelines that allows users to view and access previous pipeline runs directly from the Pipeline result page. This is achieved by adding a 'Runs' dropdown that displays the most recent 10 runs, and by including the run number in the URL for easy sharing and bookmarking. This feature aids in diagnosing issues by enabling comparison of results, tracking progress, and troubleshooting failed runs.
  38. Supercharge your pipeline with 16x step sizesIntroduces 16x build sizes for Bitbucket Pipelines runners, offering 32 CPU cores and 64GB of memory, a doubling of resources compared to the previous 8x build size. This enhancement is aimed at supporting users with increasingly complex projects requiring greater computational power.
  39. Introducing the Jenkins to Bitbucket Pipelines migration toolIntroduces an open-source, automated tool to convert declarative Jenkins files into Bitbucket Pipelines YAML syntax. The tool translates common Jenkins features, marks unconverted elements for manual review, and is extensible to support custom Jenkins plugins and functionality through custom translation logic. This complements existing guides and aims to simplify the migration process from Jenkins to Bitbucket Pipelines.
  40. What’s new & what's coming to Bitbucket CloudThis post details several new and upcoming features for Bitbucket Cloud, focusing on CI/CD and developer productivity. Key contributions include: AI-generated PR descriptions and AI code review using ChatGPT pipes; Rovo integration for unified search and code chat; UI revamps for pull requests with iterative review and auto-assignment of reviewers based on a CODEOWNERS file; custom merge checks with global workspace-level settings; enforcement of private workspaces; and roadmap items for enforced signed commits. For CI/CD, it introduces dynamic pipelines for programmatic management, a next-gen CI/CD runtime with significantly increased CPU/memory (8x, with 16x coming), and roadmap items for ARM/multi-arch builds, third-party secret management, extended step execution times, automated test suite optimization, and Jenkins migration tooling.
  41. Migrating Pipelines 1/2x steps to our new CI/CD runtimeThis post details the migration of Bitbucket Pipelines' 1x and 2x build sizes to the new CI/CD runtime. It explains the shift from shared CPU pools to dedicated CPU allocation, where 1x builds will now show 2 cores (maintaining similar compute levels) and 2x builds will have approximately double the CPU allocation compared to before, aligning with their 2x memory allocation. The migration is scheduled for September 17th, 2024, and requires users leveraging IP allowlisting to update their configurations to the new IP address ranges.
  42. Bitbucket Pipelines Runner - Upgrade RequiredThis post announces the mandatory upgrade to Bitbucket Pipelines runner version 3.0.0 by December 2, 2024, to maintain functionality for artifacts and caches. It details the impact of not upgrading (steps utilizing artifacts/caches will fail) and provides updated IP and URL allowlisting guidance for AWS S3 file storage, specifically mentioning the need to unblock S3 endpoints in us-east-1 and us-west-2 regions.
  43. Announcing our new CI/CD runtime, with up to 8x faster buildsThis post announces the general availability of a new, next-generation CI/CD runtime for Bitbucket Pipelines. This new runtime enables significantly larger instance sizes for builds, offering up to 8x more CPU and memory (4x: 8 cores/16GB, 8x: 16 cores/32GB). Builds using the new `4x` and `8x` sizes will automatically use this new runtime. The legacy runtime for `1x` and `2x` sizes will be retired on September 17th, 2024, at which point these sizes will also migrate to the new runtime. The post warns of potential rare incompatibilities with specific runtime environment elements and advises testing. It also highlights the need to update IP allowlisting for internal networks prior to the legacy runtime retirement.
  44. Introducing Dynamic Pipelines: A new standard in CI/CD flexibilityThis post introduces Dynamic Pipelines for Bitbucket Cloud Premium, a new capability that allows CI/CD workflows to be dynamically altered in real-time using serverless functions built on the Forge platform. It details how these functions can modify pipeline configurations before execution, enabling greater flexibility and customization. The post outlines use cases for both individual teams (repository-level) and organizations (workspace-level), including standardizing docker image usage, enforcing approved runners, selective test execution, creating reusable workflow blocks, cost attribution, and custom pipeline syntax generation. It also provides guidance on getting started with Forge and Dynamic Pipelines.
  45. Uplevel your DevOps automation with new Bitbucket Cloud extensibilityThis post announces the General Availability (GA) of custom merge checks in Bitbucket Cloud, moving from open-beta. It details how custom merge checks allow teams to define specific conditions, rules, and processes as code to enforce before pull request merges. It also introduces upcoming workspace-level custom merge checks for organization-wide policy enforcement and the concept of 'required' vs. 'recommended' checks. The post also announces Dynamic Pipelines, a near-term roadmap feature, which will enable CI/CD workflows to adapt in real-time based on code and external context, with both repository-level and workspace-level capabilities planned for launch in late April.
  46. Upcoming changes to pull requests and merge check configurationThis post details the upcoming General Availability (GA) of custom merge checks in Bitbucket Cloud, introducing `on-merge` checks as a new capability that runs immediately after a merge is initiated. It also standardizes the UI for both classic and custom merge checks, consolidates them into a single card on pull requests, and introduces branch configuration options for custom merge checks. Furthermore, it introduces the concept of "Recommended" vs "Required" custom merge checks, allowing for more granular control over enforcement.
  47. Custom Merge Checks in Bitbucket CloudThis post introduces Custom Merge Checks for Bitbucket Cloud, powered by Forge. It details how these checks can be built and enforced at the repository level, with plans for workspace and project-level enforcement. The post explains the triggers (`on-code-pushed` and `on-merge`) and provides examples of use cases such as Jira issue validation, security scanning, and code owner checks. It also outlines the steps for developers to get started building and installing these custom merge checks.
  48. Five exciting new features coming to Bitbucket CloudThis post introduces the upcoming integration of Forge with Bitbucket Cloud, enabling the development of custom merge checks. It details how organizations can define their own criteria for pull request merges, providing examples such as time-based restrictions, team-specific approvals based on modified files, and feature flag validation. The post also announces the upcoming EAP for Generative AI in comment and PR description editors for summarization and tone adjustment, and the design phase for AI-powered code review suggestions. Finally, it discusses the development of Unified User Management to centralize user, group, and permission management in Atlassian Admin, connecting with third-party identity providers.
  49. Announcing support for Linux ARM Runners in Bitbucket PipelinesThis post introduces support for Linux ARM self-hosted runners in Bitbucket Pipelines. It details how to configure ARM runners in repository/workspace settings, specify `runs-on` labels in `bitbucket-pipelines.yml` for ARM compatibility, and provides guidance on checking image ARM compatibility using `docker manifest inspect` and `docker inspect`. It also mentions the need for ARM-compatible pipes and links to technical documentation.
  50. Announcing Linux Shell Runners in Bitbucket PipelinesThis post announces the general availability of non-containerized Linux Shell Self-Hosted Runners for Bitbucket Pipelines. It details how to set up and configure these runners, allowing CI/CD steps to access host hardware and remove memory usage restrictions. The post also provides a `bitbucket-pipelines.yaml` configuration example for using these runners.
  51. Announcing macOS Runners in Bitbucket PipelinesThis post announces the official release of macOS self-hosted runners for Bitbucket Pipelines, moving them from beta to GA. It details how to set up and configure these runners, including specifying them in the `bitbucket-pipelines.yaml` file using the `runs-on` parameter with the `macos` label. The post highlights the benefits of using self-hosted runners, such as avoiding build minute charges and having direct access to macOS hardware.
  52. Migrating complex CI/CD workflows in Bitbucket CloudThis post details the migration of Bitbucket Cloud's CI/CD workflows from a fragmented, multi-tool (Bamboo and Bitbucket Pipelines) system to a unified, end-to-end pipeline within Bitbucket Pipelines. It outlines the team engagement strategies, the key metrics used to measure CI/CD efficiency (build time, lead time, failure rate, MTTD, MTTR, deployment frequency), the design of the unified pipeline, and an iterative 3-step migration process. The post highlights the optimization of manual steps to achieve 'push-button' releases and presents the resulting improvements in pipeline metrics, deployment frequency, and branching strategy. It also mentions the move towards continuous deployment.
  53. New product features - default tasks, in-progress builds & moreThis post introduces several new features and improvements for Bitbucket Cloud. For pull requests, it adds default tasks, a merge check for in-progress builds, the ability to change the destination branch directly, and refactors branch permissions and merge checks into a unified 'Branch Restrictions' feature. For Pipelines, it adds Docker BuildKit support with benefits like improved performance, secrets management, and caching, and launches an open beta for Linux shell runners that provide more flexibility by allowing direct access to host hardware. Bug fixes include improvements to workspace invitation deliverability and the UI for hiding repositories in a deleting state.
  54. Announcing support for Windows runners in Bitbucket PipelinesThis post introduces support for self-hosted Windows runners in Bitbucket Pipelines. It details how to configure and use these runners, which allow for .Net framework builds on user-provided Windows infrastructure. The runners are non-containerized, offering direct hardware access and no memory restrictions. The configuration involves specifying 'runs-on: - windows' in the bitbucket-pipelines.yaml file.
  55. Predefine values of custom pipeline variablesIntroduced the `allowed-values` property for custom pipeline variables in Bitbucket Pipelines. This property allows users to define a dropdown list of predefined values for a variable, improving user experience and reducing configuration errors by preventing free-text input. An example pipeline configuration and a screenshot of the 'Run pipeline' dialog are provided.
  56. Announcing the Bitbucket Cloud Migration AssistantIntroduces the Bitbucket Cloud Migration Assistant, an Atlassian-supported app for automating the migration of Bitbucket Server instances to Bitbucket Cloud. It supports migrating projects, repositories (up to 4GB), pull request diffs and metadata (comments, users, authors, reviewers), and users. It notes that user permissions and groups need to be set post-migration. The post also provides links to download the app, plan the migration, and learn about other Atlassian cloud migration tools. It highlights key Bitbucket Cloud features like Jira integration, built-in CI/CD (Bitbucket Pipelines), DevSecOps integrations, and enterprise-grade security.
  57. Introducing default values for custom pipeline variablesIntroduces the ability to define default values for custom pipeline variables in Bitbucket Pipelines. This feature aims to reduce manual input during custom pipeline triggers, prevent build failures due to forgotten or mistyped variables, and improve clarity for other developers. It also details how default values are used when creating pipelines via API and when pipelines are scheduled.
  58. It's official! Announcing Runners in Bitbucket PipelinesThis post announces the official release of Bitbucket Pipelines Runners, moving from beta to general availability. It details the benefits of using self-hosted runners, including custom build configurations, access to internal systems, and hybrid workflow optimization. Key features highlighted are workspace-level runner management, multiple runners per machine, increased memory limits (up to 32GB), and the ability to specify runners for each step using labels. Technical documentation and a feature ticket link are provided.
  59. Changes to Bitbucket Pipelines due to crypto mining abuseIntroduced two-step verification as a mandatory requirement for new Bitbucket Cloud users to enable Bitbucket Pipelines, mitigating crypto mining abuse. This change impacts new users' CI/CD user experience. Also detailed existing improvements such as strictly enforcing pipelines minutes quotas, automatic detection and blocking of abusive accounts, terminating in-progress pipelines of abusive accounts, and cluster isolation for trusted vs. untrusted workloads.
  60. We are rolling out Docker v20 to Pipelines in June 2021This post announces the progressive rollout of Docker v20 to Bitbucket Pipelines throughout June 2021. It highlights that builds using the `docker service` in `bitbucket-pipeline.yml` may require updates to interact with the Docker daemon. It recommends updating local Docker to v20 and testing builds locally, providing an example of updating `testcontainers-java` to version 1.15.1 or newer. It also links to Docker Engine v20.x.x release notes and API v1.41 version history.
  61. Automate (and scale) your Android deployment with Bitbucket PipelinesThis post introduces a new Android template for Bitbucket Pipelines, demonstrating how to automate the building, testing, and static analysis of Android projects. It details the use of Docker containers with the Android SDK, Gradle for builds, caching for dependency speed-up, and artifact storage for build outputs and reports. The post also covers running unit tests and optimizing CI build times through parallel steps and modularization of Android projects. It highlights how these techniques enable scaling CI for large Android projects.
  62. Manual steps in parallel groups available for PipelinesThis post introduces the ability to combine manual step triggers with parallel groups in Bitbucket Pipelines. It provides a YAML example demonstrating how to configure a pipeline where a manual step can be part of a parallel execution block, and subsequent steps only run after all steps in the parallel group (including the manually triggered one) have completed successfully. It also illustrates how failed steps in a parallel group prevent subsequent steps from executing. The post clarifies that parallel groups cannot contain deployment steps to different environment types but can include multiple deployments to environments of the same type.
  63. Conditional steps and improvements to logs in Bitbucket PipelinesThis post introduces improvements to Bitbucket Pipelines, including log searching, log deletion for sensitive information, and conditional step execution using the `changesets` condition. The `changesets` condition allows steps to run only if modified files match specified `includePaths`.
  64. Cloning another Bitbucket repository in Bitbucket PipelinesThis post details how to configure Bitbucket Pipelines to clone another Bitbucket repository using SSH keys. It explains the process of generating SSH keys within Bitbucket, adding the public key to the target repository's access keys, and then using `git clone` with the SSH URL in the pipeline script. This enables pipelines to access submodules or other dependent repositories.
  65. Automate publishing your Android application with Bitbucket Pipelines and GradleThis post details how to automate the publishing of an Android application to Google Play using Bitbucket Pipelines and Gradle. It outlines the necessary prerequisites (Google Developer account, Google Play application), pipeline configuration steps (build environment setup, debug and release builds, testing, publishing to internal track), and the required pipeline variables (GOOGLE_API_KEY_JSON, SIGNING_JKS_FILE, SIGNING_KEYSTORE_PASSWORD, SIGNING_KEY_ALIAS, SIGNING_KEY_PASSWORD). It provides YAML snippets for building, testing, and publishing to the 'Internal' deployment environment using the `gradle-play-publisher` plugin. It also describes how to manually trigger promotions to Alpha, Beta, and Production tracks using Bitbucket Deployments.
  66. Continuous Delivery for Django projects with Bitbucket Pipelines and AnsibleThis post details how to set up a continuous delivery pipeline for Django projects using Bitbucket Pipelines and Ansible. It explains the configuration of `bitbucket-pipelines.yml` to automate deployment to a production environment upon pushing to the master branch. Key steps include installing Ansible within the pipeline, executing an Ansible playbook for deployment tasks (code update, dependency installation, database migration, static file collection, server restart), and setting up SSH key authentication between the pipeline and the target server. The post also touches upon the benefits of automation for reproducibility and error reduction.
  67. Introducing redeployments for Bitbucket PipelinesIntroduces redeployment support for Bitbucket Pipelines, allowing users to restore the last successful deployment to a given environment with a few clicks. This feature simplifies rolling back failed releases by rerunning successful deployment steps and provides improved visibility into redeployments through a deployment preview screen showing affected commits, code, and Jira issues. The post outlines the prerequisites for enabling the 'Redeploy' button and the steps to perform a rollback.
  68. Build flexible CI/CD pipelines with custom PipesThis post introduces the concept of custom Bitbucket Pipes, enabling users to create reusable CI/CD logic for their pipelines. It explains the use cases for custom pipes, the distinction between simple and complete pipes, and provides links to further documentation and examples. It also announces a contest for users to share their custom pipes.
  69. How to update build status for commits on Bitbucket ServerThis post details how to integrate Jenkins pipelines with Bitbucket Server to update commit build status. It explains the configuration of the Bitbucket Server Notifier plugin in Jenkins, how to generate `notifybitbucket` pipeline scripts, and how to add a parameterized function to the Jenkinsfile to send 'INPROGRESS', 'SUCCESS', or 'FAILED' notifications for specific commits. It also shows how to view these build statuses in the Bitbucket Server 'All Branches Graph'.
  70. An introduction to Bitbucket PipelinesThis post introduces Bitbucket Pipelines as a CI/CD tool integrated within Bitbucket Cloud. It highlights its easy setup, cloud-native nature, and the concept of 'Pipes' for integrations with third-party tools. It also details deployment functionality for mature workflows, visibility integrations with Jira and Slack, and a consumption-based pricing model based on build minutes. The post encourages adoption of CI/CD practices.
  71. Practice DevOps with custom Pipes reusing CI/CD logicThis post introduces custom Pipes for Bitbucket Pipelines, allowing DevOps teams to abstract and reuse custom CI/CD logic (deployment scripts, testing, notifications) across repositories. It details the creation of a simple Python-based custom Pipe, including repository structure, script writing using the `bitbucket-pipes-toolkit`, Dockerfile creation, local testing, and release automation using Bitbucket Pipelines. The benefits highlighted are improved dev speed, reduced duplication, simplified build configuration, and versioning of build scripts.
  72. Setting up a CI/CD pipeline with Spring MVC, Jenkins, and Kubernetes on AWSThis post details the setup of a CI/CD pipeline for a Spring MVC application using Jenkins and deploying to Kubernetes on AWS EKS. It covers Dockerfile creation for packaging the application, pushing Docker images to a registry, setting up an AWS EKS cluster, configuring Replication Controllers and Services for Kubernetes deployment, and implementing rolling updates for zero-downtime deployments. A Jenkins pipeline script is provided to automate the build, push, and deployment process.
  73. Scaling Android Deployment with Bitbucket Pipelines and FastlaneThis post details how Traveler.today automated the deployment of dozens of Android applications from a single codebase using Bitbucket Pipelines and Fastlane. It describes configuring Bitbucket Pipelines for server deployment based on Git tags, including setting up environment variables, using Maven for builds, and SCP/SSH for deployment to DigitalOcean. It also outlines the use of Fastlane for mobile app deployment, including updating databases, building signed APKs with specific configurations, and deploying to Google Play. The process reduced deployment time per app from hours to minutes.
  74. Adding human interaction back into automated buildsIntroduces the ability to pass custom variables when triggering custom pipelines, enabling parameterized builds for specific sub-projects, test suites, or deployment environments. This simplifies pipeline configurations by reducing repetition and maintenance overhead compared to defining separate pipelines for each input combination. Variables are exposed as environment variables within the pipeline.
  75. Level up your code review with continuous integrationThis post introduces the concept of pull request pipelines in Bitbucket Pipelines, which automate checks when a pull request is created. It explains how these pipelines perform a local merge of source and destination branches before executing tests, providing a preview of how code changes will behave upon merging. The post contrasts pull request pipelines with branch pipelines and suggests use cases for each, including splitting tests between fast unit tests in branch pipelines and slower integration/browser tests in pull request pipelines. It also details how to configure these pipelines using YAML and enforce successful builds as a merge check.
  76. Faster feedback on merges with pull request pipelinesThis post introduces the capability to configure Bitbucket Pipelines to run specifically for pull requests. This involves adding a `pull-requests` keyword to the `bitbucket-pipelines.yml` file, which triggers a temporary merge of the pull request changes with the destination branch. The defined pipeline then runs on this merged result, providing early feedback on breaking changes and increasing reviewer confidence. The feature allows for different pipeline configurations based on branch prefixes and can be used to run a full test suite for critical branches or a smaller set of tasks for feature branches.
  77. Better release management with JFrog and Bitbucket PipelinesThis post describes the integration of JFrog Artifactory, Xray, and Bintray with Bitbucket Pipelines for release management. It details a diagram showing the workflow: collecting and publishing npm build information to Artifactory, Bitbucket Pipelines automating the build and test flow using Artifactory as a repository manager, JFrog Xray scanning packages for vulnerabilities and license compliance, promoting builds to production, and JFrog Bintray distributing images. It also introduces an open-source Artifactory Add-on for Bitbucket Pipelines that provides a unified dashboard for visibility into artifacts created during a release cycle, showing build information, promotion statuses, and Bintray distribution.
  78. Rerun your failed pipeline stepsIntroduces the ability to rerun only failed steps in a Bitbucket Pipeline, reducing the need to rerun the entire pipeline and saving time and resources. Also adds visibility into who reran failed steps and how many times.
  79. Instant notifications for your Bitbucket Pipelines buildsThis post introduces instant notifications for Bitbucket Pipelines builds to Slack. It allows per-channel and per-branch notification customization, enabling users to rerun builds directly from Slack when they fail, and provides updates when a pipeline is fixed. It also allows users to unfurl pipeline links in Slack to see contextual information without leaving the channel. The post details how to connect Bitbucket repositories to Slack and advises users to uninstall legacy Slack integrations.
  80. Why Bitbucket Pipelines is the best CI/CD tool for your Docker-based softwareThis post details improvements to Bitbucket Pipelines' Docker support, focusing on enhanced caching mechanisms (image, layer, and custom caches) that significantly reduce Docker build times. It also introduces increased memory limits (up to 7GB) for builds and services, and enables the use of `docker-compose` for spinning up entire applications within pipelines for integration testing. The post highlights the benefits of these improvements for developers working with Docker-based software.
  81. Speed up your build with parallel steps in PipelinesIntroduced parallel steps in Bitbucket Pipelines, allowing multiple steps within a pipeline to run concurrently. This feature is configured using a `parallel` block in `bitbucket-pipelines.yml` and is primarily designed for parallelizing test suites or large compute tasks. The post provides a configuration example and discusses the benefits of faster feedback loops and time savings for developers, while noting that billing is based on total execution minutes.
  82. Introducing Bitbucket Deployments: Confidence to release early and oftenThis post introduces Bitbucket Deployments, a new feature that integrates deployment tracking directly into Bitbucket. It provides a dashboard for visibility into which software version is running in each environment (test, staging, production) and a complete deployment history. It also ties code changes to deployments, allowing users to see which code went into a specific deployment. A promotion workflow is included to move verified builds between environments. The feature is enabled with a single line of code in the Bitbucket Pipelines YAML configuration.
  83. Getting started with Bitbucket Pipelines in SourcetreeThis post describes how to integrate Bitbucket Pipelines build status visibility into Sourcetree for macOS. It outlines the steps to sign up for Bitbucket Cloud, enable Bitbucket Pipelines by adding a bitbucket-pipelines.yml file to a repository, and then configure Sourcetree to display the build status by adding the Bitbucket Cloud account and pulling the repository.
  84. Pipelines manual steps for confidence in your deployment pipelineIntroduces manual steps to Bitbucket Pipelines, allowing users to configure specific steps (e.g., deployments) to be triggered manually. This provides greater control over the CI/CD process, enabling manual testing or optional expensive automated tests before proceeding. Configuration is done via `trigger: manual` in the `bitbucket-pipelines.yml` file.
  85. Build status within Sourcetree for macOSThis post introduces the beta integration of Bitbucket Pipelines build statuses directly into Sourcetree for macOS. This feature aims to provide developers with immediate context on code quality by displaying build statuses within the commit graph, reducing the need to switch between tools. It also leverages macOS notifications for build completion updates and allows users to view run details within Sourcetree, with a simple click to access specific logs in Bitbucket Cloud.
  86. Add structure to your pipeline with multiple steps in Bitbucket PipelinesIntroduced support for multiple steps in Bitbucket Pipelines, allowing users to structure pipelines logically, test against different build environments, and separate deployment steps. Steps run in separate Docker containers and can be configured with different Docker images, caches, services, and artifacts. This is a stepping stone towards parallel and manual steps.
  87. Bitbucket Pipelines can count! (Builds are now numbered)Introduced the `$BITBUCKET_BUILD_NUMBER` environment variable, an incrementing build number for each build in a repository, available across all branches and for reruns. This number can be reset via the REST API. The post clarifies that this feature is not intended for semantic versioning or human-readable version numbers.
  88. Bringing you speed, power and flexibility with 12 new features in Bitbucket Pipelines.This post highlights 12 new features added to Bitbucket Pipelines in the 6 months prior to August 2017, focusing on speed, power, and flexibility. Key additions include dependency caching (up to 100% speedup), Alpine Linux support, public image caching, command duration visibility, HipChat/Slack notifications, building Docker images, service containers for database testing, Amazon ECR support, scheduled pipelines, SSH key management, build numbers, and a bitbucket-pipelines.yml validator.
  89. Generate SSH keys for Bitbucket PipelinesThis post introduces a new configuration screen for Bitbucket repositories that allows users to generate and configure SSH keys for their pipelines with a single click. It also simplifies adding remote hosts to the SSH known_hosts file by automatically pulling the host's public key and allowing verification of the fingerprint. This significantly reduces the time and error-proneness of configuring SSH access for Bitbucket Pipelines.
  90. Bitbucket Pipelines adds support for Alpine LinuxThis post details the addition of support for Alpine Linux-based Docker images in Bitbucket Pipelines. Previously, Pipelines required a bash shell, which is not present in Alpine. The team modified Pipelines to fall back to `/bin/sh` when `/bin/bash` is unavailable, enabling the use of lightweight Alpine images for build containers. This change reduces download and startup times for builds.
  91. Bitbucket ❤️ Unity Cloud BuildThis post announces a new integration between Bitbucket and Unity Cloud Build. It describes how Unity Cloud Build provides automated builds and continuous integration for Unity projects hosted on Bitbucket. The integration posts build logs and artifacts to Bitbucket as build statuses, allowing users to jump from source code to a built, playable version of their game. It supports multiple platforms (Android, iOS, Windows, macOS, Linux, WebGL) and integrates with Bitbucket's merge checks to prevent merging failing code. The post also provides instructions on how to set up the integration and mentions the teams' presence at GDC 2017.
  92. Introducing the build status API for Bitbucket CloudIntroduces the build status API for Bitbucket Cloud, allowing CI tools to report build status (passing/failing) directly to Bitbucket. This enables at-a-glance feedback on commits, branches, and pull requests within the Bitbucket UI, saving developers time by eliminating the need to check separate build servers. The API provides detailed build and test results for commits and integrates with pull requests to indicate if tests pass before merging. The post encourages integration with various CI tools.