Atlassian

Merge Queues for Bitbucket Cloud, now in open beta Teams are shipping more code, faster than ever, as they increasingly automate their processes with CI/CD and AI. But high-velocity pull-request workflows and large monorepos, where many PRs are merged continuously, are feeling the pain as they grow: pull requests race to merge before the branch changes again, “green” builds still break due to semantic merge conflicts, and developers are stuck babysitting merges instead of building features. The result is friction, slower releases, and too much time spent managing branch stability instead of improving the product. Today, we are announcing the open beta of Bitbucket merge queues for Standard and Premium plans in Bitbucket Cloud . Merge queues allow teams to automate, sequence, and validate pull request merges, ensuring every change lands on a green, production-ready main branch, without last-minute breakages or endless rebases. And developers stay in the same Bitbucket pull request experience they use today, just with a smarter, automated merge path that cuts down on traffic jams, rework, and flaky releases. What’s new: merge queues, built in Bitbucket now automatically sequences and validates your pull requests by allowing you configure merge queues. No need for extra scripts, plugins, or manual rebases. Just open your PRs as usual, and Bitbucket does the rest: Queue pull requests instantly: Just queue your pull request whenever all checks on your Pull request pass. Keep “target branch” green: The Pull requests run against the latest target-branch code plus dependent pull-requests, and merged only when all the checks pass, keeping the target branch green and eliminating last-minute surprises. Stay in control: Prioritise urgent fixes, clear or drain the queue with a click. Why it matters Merge queues are especially valuable in high‑traffic repositories where multiple developers are frequently merging to the same target branch. For those cases, the benefits are clear: 1. Ship faster: No more waiting on manual rebases o...

Rovo Dev in Frontend Platform Engineering – AI for small tasks, AI for big tasks TL;DR Rovo Dev really shines with big scale automating platform engineering tasks – like migrating between libraries, where similar patterns need to be applied across whole repo and where codemods might not be able to cover all the cases. Rovo Dev doesn’t limit to just execution – it can help with all the stages of delivery : planning / spikes – building PoC / playgrounds / classifying changes writing harness / orchestration for executing migration tasks building validation steps which will be used as a feedback loop for the coder agent The experiment to migrate styled-components to @compiled css-in-js resulted in migrating majority of usages (most of them tricky edge cases, where codemods couldn’t update them) in short amount of time (total time to generate PRs within 3 days and minimal supervision – optimistically estimated as 14 engdays using artisan way of development). Additionally, to lower PR review pain (and decrease time to merge), Rovo Dev helped to build validation tools – used by both Rovo Dev to correct its mistakes and give the snapshot of styles to the reviewing team with highlighted differences (if applicable). Rovo Dev can help a lot with many common platform tasks – one of them which I have stumbled upon most recently is migration from library A → library B (outdated styled-components to Compiled css-in-js ). For migration-type of tasks the execution can take significant amount of time, despite the work being quite repetitive (however nuanced from case to case) – that’s where I hoped Rovo Dev help to close the gap of codemods. Preparation for the big task – migrating Styled Components to Compiled The main experiment was how to run bigger spec-driven project of mass migration of almost 200 files including styled-components library to their Compiled replacement. To make Rovo Dev to execute on an one shot bigger task we need to organise spec document describing whole project. Particular agents will consume / get as a context relevant parts of the docu...

Streaming Server-Side Rendering in Confluence Over the past two years the Confluence team has spent a significant amount of time investing into improving performance – halving the 90th percentile latency for completing page loads https://community.atlassian.com/forums/Confluence-articles/Confluence-Performance-Journey-2x-Faster-in-1-Year/ba-p/3097191 . One of the big change we have made in the last 12 months has been to introduce React’s new streaming capabilities for server-side rendered (SSR) apps. This has allowed us to significantly lower the amount of time it takes to make content visible in the browser and opens up further opportunities to improve Confluence’s performance. We’ve observed about 40% improvement for the first contentful paint. In this post, we cover how we integrated React 18’s streaming capabilities into Confluence to reduce the time it takes to display content on page load. These foundations have enabled us to further optimize how the page is loaded – ensuring pages are visible and interactive faster. Page Load Performance Metrics In order to understand how streaming impacts page load performance – we will first cover what metrics we use at Atlassian to measure and understand page loading performance. We track a fairly broad range of metrics for page load times – but some key metrics we track include: First Contentful Paint (FCP) measures the time it takes for the first visual elements to be rendered within the browser when loading a page. This could be the entire page or just a small first subset like the navigation menu. A low FCP typically helps users see a page loading earlier, making the page feel more responsive. Time to visually complete (TTVC) measures the time it takes to render the entire page, in particular, how long it takes for the entire page to settle. Importantly, TTVC requires elements to be loaded and not to shift; as such, a low TTVC number makes the page feel significantly faster. On the Confluence team, our target is to have 90% of the page visible and stable as quickl...

Editor-common heading icons broken Editor-common heading icons broken by tsRewriteRelativeImportExtensions in published ESM** Affected package:** @atlaskit/editor-common@112.18.9 , file dist/esm/quick-insert/assets/index.js Description: The importHeading() function wraps paths in _tsRewriteRelativeImportExtensions() , which is a TypeScript 5.7 --rewriteRelativeImportExtensions runtime helper. This is a no-op in compiled .js output, but prevents Webpack 5 from statically analyzing import() expressions, resulting in “Critical dependency” warnings and heading icons failing to load (not displayed) . All other ~24 icons in the same file use plain string literals and work fine. 2 posts - 1 participant Read full topic

Is there an API to get groups by product in Atlassian Admin API? Hi, Is there an official endpoint to get the groups associated with a specific product (e.g. Jira Core, Confluence)? Currently I’m guessing the product from the group name/description using regex, which is fragile. 1 post - 1 participant Read full topic

Curl search cql with hex encoded url no longer working We are using a bash script to update content on confluence cloud. First the script is searching a the page id with the page title using $CONFL_API_END= https://my-company.atlassian.net/wiki/rest/api/content/ curl -so- -H “$AUTH_HEADER” -X GET -L “$CONFL_API_END/search?cql=space=%22$_space%22%20and%20title=%22$_query%22%20and%20type=page” $_query and $_space are hex encoded , the space is ok , but since a couple days the title is no longer found "error: Page ‘%4F%76%65%72%76%69%65%77%20%41%63%63%65%73%73%20%53%77%69%74%63%68%65%73’ not found. is something changed on the API ? 1 post - 1 participant Read full topic

Inconsistent adf PDF Export Hi there, i have an Confluence Macro written in Forge. The macro defines an adfExport function in the manifest.yml. In general, the export works but sometimes the font size is extremly big and sometimes it is what i would expect to be normal. I tried adding CSS into my confluence Instance but that does not seem to do the trick. I also added 2 Screenshots of the exports. I was on the export page and the only thing i did was pressing f5 to re-render the export and this are the 2 results of that. Does any1 have any idea how to get an consistent result everytime a user exports my plugin? Best regards 1 post - 1 participant Read full topic

Introducing Agentic Pipelines: AI automation for chores devs don’t want to do Bitbucket Pipelines has always been an engine for automating more than just CI/CD, but today, Pipelines takes a first step towards a full agentic automation platform for all the manual, tedious, repetitive work that happens before and after code creation. You’ve probably seen the stat: Development teams spend 84% of their day doing things other than building features . A lot of this work is: Toilsome tasks : Constantly updating documentation to keep up with changes in code Tech debt repayment : Cleaning up feature flag code after a feature is released Troubleshooting automation issues : Reading through logs to understand why a build failed This work matters, but it’s not very fun. It’s often high-effort but low-value; manual, repetitive, and easy to de-prioritize in the moment. Sometimes we skip doing it entirely, but it always turns into tech debt and you pay the price later. Agentic Pipelines is a new way to delegate those tasks to AI, orchestrating a fleet of agents to automatically, and routinely, handle the repetitive chores so you can get back to solving the fun, cool problems. Why Agentic Automation for this kind of work? Many teams already rely on tools like Bitbucket Pipelines to automate CI/CD workflows, with Bitbucket acting as the central orchestration platform. Agentic Pipelines takes that model and extends it beyond the core dev loop of “build, test, deploy.” Think about all the tasks you could continuously automate that are straightforward but time-consuming, easy to defer until later, and most importantly, painful when they pile up. A concrete example is maintaining documentation. Keeping a repo’s README or knowledge base in sync with reality involves: Keeping the project description aligned with how the code actually works Updating installation and configuration instructions as the setup changes Refreshing examples or API docs (and suffering the compounding pain when they’re out of date) Maintaining contribution guidelines, ownership info, and code ...

routeApi access from another Forge application Hi all, I have create a test App leveraging the routeApi module ( https://developer.atlassian.com/platform/forge/manifest-reference/modules/api-route/ ). I followed the tutorials: declared custom scope push them to forge environment added the route Api module declaration deployed the app on my instance. I see the part of the tutorial to create an 3LO to access the route from “outside”, I would like to do it from another Forge App. When hitting the url, I get a 401. My questions: is there a trick to make this work ? is this even supposed to work ? what else could I use to make 2 Forge applications communicate more than payload less AppEvents ? Regards, 1 post - 1 participant Read full topic

All calls against Rovo from Jira automation suddenly fail TL;DR Calling agent from Jira automation is now failing 100% due to the agent timing out. Anyone else seeing the same thing? Full I have been testing some automation rules that trigger an agent to do some work on Jira issues. Today it suddenly isn’t working anymore. The automation calls the agent, but then never gets any response, so it eventually aborts due to taking too long. So then I started testing a bit, and it seems it fails 100% of the time whenever an automation calls any agent. Any automation calling Rovo ends up aborted and the audit log ends with the agent call (no additional info provided, presumably because it never got a response). Anyone seen this before or is facing the same issue? 2 posts - 1 participant Read full topic

Bitbucket Packages now supports Maven and npm Few months back we launched Bitbucket Packages with a native container registry , giving teams a way to manage container images right alongside their code and pipelines. Today, we’re expanding that functionality and now Bitbucket Packages support Maven and Node Package Manager (npm), bringing JavaScript and Java package management into the same platform where your team already writes code, reviews pull requests, and runs pipelines. Why we built this? When we launched container registry support, it addressed a genuine need for teams managing container images. But customers told us containers alone weren’t enough. Their workflows cut across multiple package types, and while container images were taken care of, npm and Maven artifacts still lived in entirely separate registries, each with its own billing, access controls, and learning curve. That fragmentation causes real problems: Duplicated permissions: Teams that have already configured repository access shouldn’t have to repeat that setup in a separate artifact tool. Broken flow: Jumping between tools mid-workflow slows developers down and opens the door to security gaps. Unnecessary cost: Every extra platform in the toolchain adds its own price tag and administrative burden. What’s included Publish and install Maven and npm packages: Create a package in Bitbucket, configure authentication with an Atlassian API token, and start publishing and installing packages using your existing tools like npm, Yarn, Maven, or Gradle. If you’re publishing from Bitbucket Pipelines, built-in environment variables ( BITBUCKET_PACKAGES_USERNAME and BITBUCKET_PACKAGES_TOKEN ) can be used as your authentication credentials . Unified permissions with no extra setup: Every package is scoped to a Bitbucket repository. That means the repository permissions you’ve already configured (Admin, Write, Read) automatically apply to every package tied to that repo. There’s nothing additional to configure, and no separate access control system to ...

Behind the scenes of Atlassian’s AI Builders Week At Atlassian, we are often asked how we are adapting internally to AI and transforming our R&D organization to be AI native. One lever we have used successfully is an event we call AI Builders Week . Each quarter, we bring together hundreds of product managers and designers to learn new AI skills and land tangible changes within a few days. We use this dedicated time to experiment together and embrace the change that AI presents, so our customers can thrive in this new era. When we build for ourselves, we’re also building the playbook for every team. Our first AI Builders Week focused on establishing the foundations. We grounded teams in responsible AI use, built early prototyping skills, and introduced basic agent workflows and evaluation practices. The goal was to help PM and Design crafts gain familiarity with AI, understand its potential, and learn the basics. Our most recent week was about taking it a layer deeper, with the goal of driving measurable impact. 77% of our Product Management org and 80% of our Design org attended a highly technical curriculum designed to help them use AI to make day-to-day work easier. We focused on advanced agentic workflows, production-ready prototyping, replacing time-intensive tasks with agents, and improving both evals and the golden data sets that power them. One thing that made this week especially impactful was connecting the dots from ideation to production through real, working prototypes. With support from our Design Technologists and Engineering leaders, we helped Product Managers and Designers get closer to the environments engineers use every day. As AI collapses the boundaries between crafts, there are general skills that all builders should have. We are actively enabling our teams to succeed in that future with teams across crafts learning how to commit production code and turn ideas into experiences customers can actually use. How did it go? 298 Agents were built. We saw a jump in AI intensity with super users incr...

Four warning signs your AI and collaboration investments aren’t paying off 96% of companies haven’t seen meaningful business value from AI. And yours might be one of them. IT leaders are spending big anyway – and wondering why projects still slip and service metrics refuse to improve. According to Atlassian’s AI Collaboration Index , 96% of companies haven’t yet seen meaningful business value from AI, despite widespread investment. AI has made it easier to get work done, but not easier to work together. If that sounds uncomfortably familiar, it may be because you’re bumping into one (or more) of these four warning signs. These four warning signs aren’t isolated problems but instead stages. Most IT organizations experiencing one are already sliding toward the next. The further along you are, the wider the gap between your AI investment and your actual ROI. 1. Faster people, slower teams On paper, AI should be a game-changer for IT with faster incident triage, better root-cause analysis, cleaner documentation, and more efficient change management. However, in practice, many IT leaders are seeing something different: Individual contributors generate more tickets, more docs, more “work artifacts” Local tasks get done faster But end-to-end project timelines and service metrics barely move This is the AI efficiency paradox for IT: AI accelerates individual tasks inside a fragmented system . Without a connected way of working, those gains don’t add up to meaningful organizational impact. If your AI rollout is focused purely on “personal productivity” use cases – code suggestions here, summarization there – without changing how work flows across teams, you’re likely optimizing the wrong thing. What this may look like in your team: AI drafts a spotless PIR, but the incident commander spends 40 minutes chasing context across 4 tools before anyone reads it. Agents closed twice as many low‑level tickets, yet the major incident MTTR didn’t budge because handoffs and ownership remained unclear. If this is where you are, you might think the fix is simply...

Not able to make field mandatory using UI Modifications in Jira cloud forge app on Transition screen Hi, I am trying to create a Atlassian Forge app to make fields mandatory on Create(GIC) and transition screens using UI Modifications module. I am able to make fields mandatory on Global Issue Create screen by registering the context for specific project, issue type and viewType. I have added a screen during a transition to Request Input and if I try to add context for IssueTransition viewType, the fields are not getting mandated on transition screen and not able to see any console logs as well. Can anyone please guide me on How to make this work? How to make fields mandatory or hidden on Issue transition screens in Jira cloud using Forge? Thanks & regards, Preethi H R 1 post - 1 participant Read full topic

Engineering the Forge Billing Platform for Reliability and Scale Introduction Forge is Atlassian’s cloud app development platform. It’s a serverless, Atlassian-hosted environment that allows developers to extend products like Jira and Confluence, and it powers thousands of apps running inside customer organizations. As Forge grew, we introduced usage-based pricing, so developers only pay for what they use above a free tier. With that shift came an engineering challenge that my team was tasked to solve: how to reliably measure, attribute, and bill that usage at scale. At a high level, we: Collect usage events from Forge services (compute, storage, logs, etc.) through a shared usage pipeline Transform and route that usage into Atlassian’s internal billing systems to create subscriptions and invoices Feed usage and cost back to developers via the Developer Console and APIs so they can understand, predict, and control their spend Building this end‑to‑end flow sounds like “just metering and billing,” but it quickly became a deep engineering problem: making sure we neither lose nor double‑count usage, keeping different systems in sync, and enforcing limits or budgets without impacting the reliability customers expect from Atlassian cloud. This post walks through how we put that platform together, from the high‑level architecture and core components to some of the toughest technical challenges we hit on the way to launch. Architecture Overview At a high level, Forge Billing sits in the middle of four worlds: Forge services that generate usage (compute, storage, logs, and more) A shared usage pipeline that standardizes and validates that usage Atlassian’s billing systems that turn usage into subscriptions, invoices, and payments Developer‑facing surfaces that expose usage, cost, and controls in a way that’s easy to understand You can think of the system as a left‑to‑right flow: Forge services → Streamhub -> Usage pipeline → Billing systems → Developer Console / APIs Forge services emit usage In Forge, every billable resource—such as func...

Onboarding Partner Form broken Getting the following error when trying to submit the new partner form at marketplace.atlassian.com Atlassian Marketplace Tried multiple times, a day later, still failing. The underlying service call failed. The underlying service marketplace_console_bff status code is: 412 1 post - 1 participant Read full topic

Dac-get-help forge-getting-started dac-get-help forge-getting-started 1 post - 1 participant Read full topic

AI’s speed paradox: why faster individuals don’t mean faster organizations The learnings in this blog post are based on sessions from Atlassian’s Teamwork in an AI era event featuring Forrester Senior Analyst Will McKeon-White and Atlassian’s Teamwork Lab. You can check out these sessions and others on demand. Everything’s moving faster. Decks are drafted in an afternoon. Customer emails write themselves. Reports that used to take a week now show up in your inbox overnight. But the faster your teams move, the harder it gets to keep everyone on the same page. At Atlassian, we recently surveyed 12,000 knowledge workers and over 170 Fortune 1000 executives for our forthcoming State of Teams report, building on findings from our AI Collaboration Index . The good news? We found that 89% of executives say AI has made execution faster. Unfortunately , half of those same leaders say cross-team coordination hasn’t improved at all. So what’s happening? AI can make it easier to get work done, but harder to work together Leaders know the goal isn’t “make each person faster.” When we asked where they focus their AI strategy, only a small minority said at the individual level. Many more said they want to drive value for the organization as a whole. But 58% of executives say they don’t know how to measure AI ROI at the company level, and nearly half say their high-level AI objectives are unclear. So when it comes time to show progress, they default to what’s easy to measure: individual productivity and efficiency. The actual questions should be: Are we making better decisions as a company? Are teams moving in the same direction? Is it any easier to work across functions? For many organizations, the honest answer to all three is still “not really.” Why speed without coordination backfires According to a Harvard Business Review study , about 80% of enterprise work is collaborative. By focusing almost exclusively on individual AI gains, companies may be leaving four-fifths of AI’s real potential on the table. 70% of knowledge workers say their processes and...

AI Magic in Atlassian Forge: Local Semantic Search with Forge SQL Introduction Did you know that Forge SQL can be used for semantic search ? Since Forge SQL is backed by TiDB, and TiDB supports Vector Search , it is now possible to store embeddings in the database and query them by semantic similarity. That means your app can search by meaning , not only by exact keyword matches. PingCAP highlights semantic search, recommendation systems, and Retrieval-Augmented Generation (RAG) as key use cases for this capability. This is a very practical AI pattern. Traditional search works best when users type the same words that already exist in the stored content. Semantic search works differently: both the documents and the user query are converted into embeddings, and the database returns the closest matches based on vector distance. Because of that, a query can still find the right result even when the wording is completely different. This is also one of the core ideas behind RAG . Before an LLM generates an answer, the system first retrieves the most relevant documents and passes them as context. Better retrieval usually means better answers. In this article, I will show how to build this pattern inside an Atlassian Forge app while still keeping the architecture aligned with Runs on Atlassian . In this example , embeddings are generated locally in the Custom UI frontend , stored in Forge SQL using Forge SQL ORM , and queried directly with vector search. No external AI API is required for the semantic search flow. Runs on Atlassian eligibility depends on meeting platform requirements, including around egress, so this kind of local approach can be especially useful for Forge developers. The article has two parts: How embeddings are generated in Custom UI and processed in the Forge backend A short demonstration of the app in action, with a link to the full video walkthrough Building the Local Semantic Search Flow To build semantic search inside a Forge app, we need a way to generate embeddings locally in the browser, send them to the backen...

Request for Update on RFC-124: Evolving the Marketplace Trust Program Hi @PhilipGrove , Can you please provide an update on RFC-124, and more specifically with regard to the timelines of CFA and CSP badge retirement? RFC-124: Evolving the Marketplace Trust Program Request for Comments (RFC) RFCs are a way for Atlassian to share what we’re working on with our valued developer community. It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to fi… Cheers, Remie 1 post - 1 participant Read full topic

Rovo Chat in Bitbucket now understands your Pipelines Why did your build fail? Ask Rovo, get a clear answer, and even a way to fix it, from anywhere in Bitbucket Pipeline debugging is one of the most common and most painful parts of the development workflow. In our Atlassian research: AI adoption is rising, but friction persists , over 50% of developers reported losing more than 10 hours each week searching for information, onboarding to new code, or toggling between apps. Failed pipelines make that worse, with developers spending 20–45 minutes per failure, most of it just parsing logs. With Rovo Chat, when your build goes red, you don’t have to pause to scroll through thousands of lines of output. Just ask Rovo, and you’ll get the answer – the failing step, the root cause, and what to do next – summarized, clear, and in context, right where you’re already working. What you can do Open Rovo Chat in Bitbucket and ask questions the way you actually think about your builds, no log spelunking required. Here are three simple examples: “Why did my last pipeline fail?” Get a plain‑English explanation of the root cause and not a log dump or just an error code, but a relevant answer that tells you which step failed, why it failed, and how to fix it. “When was the last successful run on main?” Check the health of your main branch at a glance. “Explain the error in this step” Turn cryptic exit codes and stack traces into plain English, so you can decide what to do next faster. Why we built this The problem isn’t that the information isn’t there. It’s that extracting meaning from raw logs is a specialized skill that takes years to develop and even experienced engineers spend more time than they should on it. Rovo Chat changes the interface. Instead of reading logs, you ask a question and get an answer. The same information, but dramatically less friction. How it works Rovo Chat brings your Bitbucket Pipelines context into every answer: The pipeline run and overall status The failing step The logs for that run Your pipeline configu...

Your feedback tool is not there to tell you what to build We spent years building and selling a feedback tool. We talked to thousands of product teams. In most of those conversations, the ask was the same: “I want to find trends in my feedback data.” Every time we leaned in and asked “what trends, specifically?” – people went quiet. It was a reflex, not a real need. Strong product people already have a view on where the product should go. They get it from the founder’s vision, the company’s strategy, and from customer signal. Think of how an LLM works: feed it enough data and it learns to predict the next token. A great PM does the same thing – every customer conversation, every chat with a Sales or Support colleague, every session recording they watch, every review of a usage dashboard, every skim through CSAT responses or online reviews, even playing with new products and vibe-coding their own prototypes. All of it nourishes their judgment until they can make confident calls without a spreadsheet. A feedback tool does not tell you what to build. It gives you the evidence to build the right thing, the right way. It supplies the rich customer context – the verbatim words, the edge cases, the current workarounds – that no roadmap captures. But evidence only flows if people keep contributing it. Sales reps logging deal objections tied to product limitations, Support agents flagging the same issue for the tenth time, customers giving up their time to help with your research – they all need a reason to keep doing it. That reason is trust: the belief that their input actually leads somewhere. A feedback system has two jobs: give product teams the customer context to build the right thing, and keep the people who supply that context invested in the process. This article is about how to do both. Don’t ship what people ask There is a quote often attributed to Henry Ford: “If I had asked people what they wanted, they would have said faster horses.” Whether Ford actually said it is debatable – but the lesson holds. Steve Jobs put it...

AI isn’t a productivity hack. It’s a team sport AI is everywhere. It drafts emails, summarizes meetings, analyzes data, and writes a first pass of project briefs. On an individual level, it’s working. In our research at Atlassian, we found that knowledge workers say AI is helping them save 76 minutes per day . That’s the shallow end – useful, energizing, and a good way to build momentum. But here’s the part we don’t talk about enough: most of that speed isn’t yet showing up in team-level outcomes. Why is that? According to Atlassian’s AI Collaboration Index , only 4% of executives say AI is helping their teams solve previously unsolvable problems. And 37% say AI has caused teams to waste time or head in the wrong direction. Those aren’t technology issues alone – they’re culture and coordination issues. I’ve been digging into this gap and rewatched sessions from Teamwork in an AI era , featuring Atlassian’s Teamwork Lab, Forrester researchers, and Adam Grant. A pattern emerged: leaders frame AI as an individual productivity tool, while the real shift lies in how teams coordinate, share context, and build trust together. The good news: you don’t need a massive rollout. You need a few practical moves you can start this week. Here are practical recommendations to help your team build momentum. 1. Use AI visibly, so your team knows it’s expected If your team never sees you using AI, they’ll assume it’s optional or risky. Silence sends a signal. I hear leaders say they want adoption, but when I ask how they use AI daily, there’s a pause. Some only tried a demo. Others use it quietly. The message their teams receive? If the boss isn’t using it out loud, maybe I shouldn’t either. Insights from Atlassian’s AI Collaboration Index shows that when leaders model usage, teams experiment more. Psychological safety research echoes this: people take cues from what leaders do . So don’t just encourage adoption – show it. Narrate your use in the flow of work. For example: “I used Rovo for the first draft.” “This agenda came from la...

The Atlassian Rovo MCP Server now supports Bitbucket Cloud The Atlassian Rovo Model Context Protocol MCP Server now supports Bitbucket Cloud. AI clients like Claude, ChatGPT, Cursor, and VS Code can now browse repositories, create commits, open pull requests, and check pipeline results, all through the same secure MCP connection that already works with Jira and Confluence. Workflows Bitbucket Cloud is where your code lives. It’s where teams commit changes, review pull requests, run pipelines, and ship releases. With Bitbucket now in the Atlassian Rovo MCP Server, your AI assistant has the full picture. Here are a few ways to put it to work: Workspace and repository management: List workspaces and repositories, browse branches, read file contents. Ask your AI assistant to explore an unfamiliar codebase without leaving your editor. Pull request lifecycle: Create PRs, get diffs, leave comments, approve, merge. Ask “show me all open PRs on platform-core waiting for my review” and get an actionable answer. Pipelines and deployments: View pipeline runs, list environments, and deployments. When a build breaks, your AI assistant can help you find the failing commit fast. Available tools Here’s the full set of Bitbucket Cloud tools now available through the Atlassian Rovo MCP Server: bitbucketWorkspace: list, get bitbucketRepository: list, get bitbucketPullRequest: create, get, list, merge, approve, comment, comments, diff bitbucketRepoContent: branch.get, branch.create, commit.get, commit.create, files.get bitbucketPipelines: list, run, get, steps, step.get, step.log bitbucketDeployments: list, get bitbucketEnvironments: list, get, create, delete, update Review our support docs on more details on the tools available today and the scopes required to use them. Current limitations Before you begin, be aware of several limitations that we are actively addressing to enable access to the Bitbucket Cloud tool on the Atlassian Rovo MCP Server. Keep the following points in mind: Org-linked workspace required: Bitbucket Cloud tools are avail...

When doing more with AI isn’t enough: Three patterns quietly undermining your team’s impact AI has made it easier to move faster, produce more, and check off tasks at a pace that would have felt impossible just a few years ago. But there’s a catch: more output doesn’t automatically translate into more visibility, trust, or impact. In fact in some cases, it quietly does the opposite. Subscribe to Work Life Get stories like this in your inbox Subscribe In our recent webinar, Work Smarter, Not Harder: 3 AI Traps to Avoid , Atlassian’s Teamwork Lab unpacked this “AI productivity paradox” and heard from hundreds of attendees who feel stuck in it. This article distills those insights into a practical guide for leaders and individual contributors alike. Read on to learn why “doing more with AI” isn’t enough, how to spot three hidden AI patterns that quietly drain visibility and impact, and how to turn AI from a simple productivity booster into a true engine for team and career growth. Three hidden AI patterns that quietly undermine team visibility and impact — and how to fix them In our research and hands‑on work with teams, the Teamwork Lab has spotted three AI patterns that often backfire. Pattern 1: The Quality Sacrificer When speed replaces intention. This shows up when AI makes it incredibly easy to produce a lot of work, very quickly. How invigorating! But when does speed start standing in for quality? A shipped document might have pristine grammar, expert structure, and a professional look. Upon a closer look, the document doesn’t answer any new questions. The key context is entirely missing or buried in niceties. This is “AI slop”: work that looks polished but lacks deeper context and judgment. In one recent survey, 37% of executives say AI has wasted their teams’ time or led them in the wrong direction due to low-quality or poorly framed outputs. “With AI, the cost of doing work drops,” says Teamwork Lab researcher Ben Ostrowski. “At an individual level, that sounds great. But when everyone is suddenly turning in five to ten times more content, the reali...

They committed to 60 engineers’ worth of work with 35 engineers Overcommitment rarely starts with bad intent. It starts with optimism and limited visibility. When Jensen Fleming, a Principal Product Manager at Atlassian, realized her team had effectively overcommitted, the issue wasn’t ambition, it was math. “We’ve committed to the work of 60 engineers, but we’re a team of 35,” she says. There was no buffer for emergencies, no reliable view of when anything would ship, and no data to back up a polite “not yet” when new requests rolled in. Something had to change. Here’s how Jensen used Jira Product Discovery (JPD) to bring the math back into the conversation. Related Article Stop rewriting your roadmap and publish it By Atlassian In Jira Product Discovery The spreadsheet that died every two weeks Like many before her, Jensen tried a Google spreadsheet. She’d list all the projects, plug in dates, assign engineers, and feel organized for about two weeks. Then dates would shift, new projects would appear, and someone would forget to update a row. “It was so much work to repeat every two weeks,” she says. This was frustrating and costly. She had to rebuild the spreadsheet and chase down updates before she could plan what came next. Building a capacity view that stays alive About four months before the webinar, Jensen built a dedicated capacity planning view inside Jira Product Discovery. She described it as “a spreadsheet in JPD,” but unlike the old version, it pulls from live project data and stays up to date. Here’s how she structured it: Split by engineering team. Jensen works with two teams: Quakus and Ragents (short for Rovo Agents). Each has its own section in the view, with separate tracking for workstreams. Monthly engineer columns. For each project, she enters the number of engineers needed per month. These columns feed into calculated roll-up fields that show total committed capacity per period. A “yes/no” resourcing column. If the monthly engineer columns are populated, the project is resourced and gets a “yes” If not, it...

If your roadmap only works for you, you’re doing it wrong A roadmap that works perfectly for you can still fail everyone else. Jensen Fleming, a Principal Product Manager on Atlassian’s Rovo Agents team, had built what felt like the ideal board in Jira Product Discovery (JPD). It tracked workstreams, timelines, delivery status, design progress, legal review, engineer assignments, Figma links … everything. Then her designer opened it and froze. “There was just too much,” says Jensen. The board wasn’t wrong. It was comprehensive, but it was optimized for the PM, not the people who needed to use it. That realization changed how Jensen thought about roadmaps. Instead of expecting every partner to navigate her control tower, she started building purpose-built views for each of them. From ‘helpful’ to ‘cannot live without’ Jensen had been using Jira Product Discovery for years, but about a year ago, her approach changed. “I unlocked JPD’s value when I discovered micro views,” she says. “It went from helpful to something I couldn’t live without.” Instead of expecting one board to serve everyone, Jensen started building purpose-built views for each recurring conversation: design, legal, support docs, front-end engineering, capacity planning. Each view showed only what that audience needed and nothing more. What clarity looks like for design Jensen’s designer, Kate, was the first beneficiary. Jensen’s main control tower has 21 fields, most of which Kate doesn’t need. Kate needs to know what requires design work, in what order, and when it starts blocking engineering. Her dedicated design roadmap includes: Design status. Projects tagged “not needed” disappear, immediately filtering out 30–40% of items. Priority order. Jensen arranges the remaining work by what Kate should tackle next. Notes. A shared field captures action items between one-on-ones so they can pick up where they left off. Start dates. If designs aren’t ready by the start date, engineering stalls, so blockers are obvious. Engineer assignments. Kate can go directly to ...

Your team’s best ideas are trapped in the wrong format. AI just fixed that. Introducing Remix with Rovo and partner agents in Confluence — a new way to instantly transform Confluence pages into charts, prototypes, presentations, and apps The last mile of knowledge Something strange happened over the past decade of work. Teams got incredibly good at creating knowledge — documenting decisions, capturing meeting notes, writing specs. But all that effort exposed a different problem: most of that knowledge never reaches the people who need it, in a format they can actually use. Confluence pages with 1 or more visual element are 18% more likely to be read by a wider audience. This isn’t a search problem. It isn’t an access problem. It’s a format problem. The knowledge exists. It’s just stuck in a form that doesn’t match how the next person needs to consume it. This means manual work: copying from docs into slides, reformatting for different audiences, and losing context, repackaging existing knowledge instead of creating new. We’re introducing two new experiences to close that gap to change how teams get value from work they’ve already created. Remix with Rovo transforms content on any Confluence page into new formats like charts, infographics, and other visuals. Pre-built third party partner agents for Lovable, Replit, and Gamma, turn Confluence content into working prototypes, starter apps, and presentations in those tools without manual copy-pasting or custom integrations. What’s available today Remix with Rovo starts rolling out today in open beta for Confluence Cloud customers with Rovo. At launch, Remix supports — data visualizations, infographics, diagrams, and charts — with more formats coming soon. Out-of-the-box partner agents for Lovable, Replit, and Gamma are in open beta and start rolling out next week. Admins can enable partner agents in Atlassian Administration under Connected Apps, with no custom agent creation or scripting required. Introducing Remix with Rovo Confluence has always been where teams go to create and share knowledg...

30.8% Faster PRs: How AI-Driven Rovo Dev Code Reviewer Improved the Developer Productivity at Atlassian Rovo Dev code reviewer reviews your pull requests (PR), proactively catching quality, security, and performance issues early while recommending best practices for code quality and maintainability. Recognized by ICSE 2026, code reviewer is observed to reduce 30.8%of the PR cycle time. Introduction Code review is a critical pillar of high-quality software engineering at Atlassian. It enables our teams to find bugs early, maintain coding standards, and share knowledge effectively. However, with the rapid growth of our products and the complexity of our codebase, manual code reviews can become a significant bottleneck in our development lifecycle. In today’s fast-paced, context-driven environment, we need ways to help our engineers ship high-quality code faster, without compromising our high standards. To address this challenge, we developed Rovo Dev Code Reviewer , an innovative and large scale AI software development agent designed to automate parts of the code review process. Code reviewer isn’t meant to replace human judgment; instead, it’s a human-in-the-loop AI partner, designed to augment our engineering workflow. We’re proud to share that after a year-long, large-scale online evaluation across over 1,900 repositories, Rovo Dev has shown significant impact—speeding up our development cycles by 30.8% and cutting human-written review comments by 35.6%. It went Generally Available (GA) on Oct 2025 after receiving widespread positive feedbacks from open Beta customers. In this blog post, we’ll dive into how we built Rovo Dev Code Reviewer , our human-centric approach to AI automation, and the compelling results from our internal online evaluation. Our research on Rovo Dev code reviewer’s online evaluation has been accepted by the 48th IEEE/ACM International Conference on Software Engineering (ICSE’26) , a prestigious software engineering conference. This research was a collaboration between Atlassian DevAI engineering team, data science team and associate professor K...

Adam Grant on how AI reshapes work: why agility beats ability The learnings in this blog post are based on Adam Grant’s session at Atlassian’s Teamwork in an AI era event. Don’t miss your chance to see Grant’s full session, available only until June 30th. When you bring AI into teams, the hard part isn’t the technology. It’s the people. That was the through-line from Adam Grant during our event, Teamwork in an AI era . Grant is an organizational psychologist, bestselling author of six books, and Wharton’s top‑rated professor for seven years running. His work focuses on how people lead, work, and live in fast-changing environments – exactly the conditions AI is creating inside today’s teams. Grant dug into how leaders can rethink team structures, culture, and their own habits so AI actually makes teamwork better, not just faster. The new currency of success For most of modern management, careers have been built on ability: demonstrating mastery, proving expertise, and being “the person who knows the answer.” According to Grant, that era is over. We live in a world now where the currency of success is not ability, but agility. It’s the people who are fastest to adapt to change, who are quickest to learn and unlearn, that are ultimately rising and succeeding and in the process, building job security.” – Adam Grant In other words, the teams that win won’t be the ones who already know how to use AI perfectly. They’ll be the ones who constantly run small experiments, such as trying multiple prompts instead of just one, comparing outputs across teammates, and learning what AI is good at, what humans are better at, and where collaboration works best. And because the tools are evolving so quickly, those experiments can’t be a one‑off pilot. Grant warns: if you keep using last year’s prompts in this year’s world, you’re already behind. Treat AI as a thought partner, not an oracle By shifting perspective on how to use AI, it invites teams to use it the way they’d use a sharp colleague; someone who helps you brainstorm options, challenge ...

Bitbucket Data Center app publishing blocked Hi, I’m encountering a contradiction between Atlassian support guidance and Marketplace behavior. I attempted to publish a Bitbucket Data Center app via the Marketplace vendor portal. What happens: The app uploads successfully. On submit, the portal returns: “App creation failed. DATA_CENTER hosting type is no longer supported. Please use Cloud hosting. Data Center apps can no longer be published.” At the same time, Atlassian support previously indicated that Bitbucket Data Center will continue under a hybrid licensing model. This raises a simple question: Are new Bitbucket Data Center apps allowed to be published on the Marketplace — yes or no? If not: does this mean that Bitbucket Data Center continues as a product, but Marketplace distribution for new apps is no longer supported? Also: for apps that were created before the December 2025 deadline and remain private — is it still possible to make them public? Right now there seems to be a mismatch between policy communication and actual Marketplace behavior. 1 post - 1 participant Read full topic

Bitbucket Data Center app publishing blocked despite official statements (topic deleted by author) 1 post - 1 participant Read full topic

Creating with Rovo: How We Built a Collaborative AI Canvas Rovo is our hero AI solution at the core of our platform. Through the Teamwork Graph , it can search across internal and third‑party knowledge, surfacing the right information from tools like Confluence, Jira, and connected apps. It can also interact with and create objects across the ecosystem – from Jira issues to Confluence pages. What it didn’t have was a fully featured creation canvas : a collaborative space where people and AI can co-create, iterate on, and refine rich content together in real time. That gap was the catalyst for Creating content with Rovo . The core insight behind creating with Rovo was simple: Creation should be a collaboration between the user and the AI, not a handoff from one to the other. This post goes behind the scenes of content creation with Rovo and covers: Why we designed it as a collaborative AI canvas, not a one‑shot writer How we handle different content types reliably (pages, whiteboards, databases) The technical choices behind ADF, SVG, and CSV‑based schemas The streaming infrastructure that lets Rovo generate and edit rich content safely in real time Core principles We didn’t want to build a standalone AI writing tool siloed inside a single product. Creating with Rovo has an entry point in Confluence, but it’s natively built on Rovo and accessible across every Rovo surface . Creation should feel like a natural extension of the chat experience: you ask a question, co‑author a page, iterate on a whiteboard, and refine a database – all in the same conversation, with the same AI that understands your context. That led to a few core design principles: Creation lives inside chat. Content starts in a canvas within Rovo chat. Once you’re happy with it, you move it into the right space or product surface. It’s a platform, not a feature. From the start, the canvas was designed to support multiple content types (pages, whiteboards, databases) and to extend to other products. Create with Rovo for Jira work items recently launched in EAP a...

Stop rewriting your roadmap and publish it Every product manager knows the feeling. You’re deep in a sprint review or halfway through a strategy session when a Slack message lands: “Hey, can you send me the latest version of the roadmap?” It’s never just one request, either. Marketing wants the roadmap grouped by launch moment; your VP requests a slide format; and legal needs their must-review items. Each request means rewriting the same information in a different way – and by the time you hit send, the content is dated. Jensen Fleming, Principal Product Manager on Atlassian’s Rovo Agents team, leads about 40 engineers and four PMs to build the custom AI agent platform inside Atlassian Studio. She described this exact spiral during a recent webinar. “One of the things that brought Jira Product Discovery (JPD) to life for me was how many times I was asked to write a new roadmap page, but in some different format, in some different way, by some different team,” she says. It’s when she turned to Jira Product Discovery to create a live source of truth that the rewrites stopped. Luckily, building that system didn’t require starting from scratch. Static roadmaps don’t scale The core issue is that static roadmaps create more work than clarity. “My problem with roadmaps and writing things down on pages is that the content is always stale,” says Jensen. “It’s not up to date unless I link back to Atlassian projects.” This is the trap: You write a roadmap on Monday. By Wednesday, two dates shift and there’s a new project. But the page still says what it said on Monday. Stakeholders read it, make decisions, then discover it’s wrong. Trust erodes, and the next time they need an update, they ping you again – because the last page you sent was unreliable. Make the roadmap the source, not the summary Jensen’s breakthrough was deceptively simple: Stop rewriting and start sharing. She built what she calls her “mega board,” a comprehensive Jira Product Discovery view organized by workstream (Admin, Maker, Platform, Quality, Se...

Forge Workflow Validator Deployment via REST API returns Invalid Request Payload or Update in Progress Hi everyone, I’ve developed a custom Forge-based Workflow Validator (static/ps-workflow-extention-linkedissue-validator) and I am now trying to automate its deployment across approximately 100 Jira Cloud workflows. The Context: The app is fully functional. I can successfully add the validator to any workflow via the UI Workflow Editor, and it behaves exactly as expected during issue transitions. However, I need to scale this across 100+ workflows, and doing so manually is will take longer time. When I attempt to replicate the UI’s action using the REST API, I am hitting constant roadblocks. The Setup: Endpoint: POST /rest/api/3/workflows/update Method: Attempting to inject the validator into the “Close” transition. The Journey so far : Initial Failures: I originally tried to use the ruleKey from the manifest directly, which resulted in Invalid Request Payload. The “Forge Wrapper” Discovery : By inspecting browser network traffic while saving via the UI, I discovered that Forge rules must be wrapped in a forge:expression-validator key, with the extension ARI placed inside parameters.key. Schema Sensitivity : Even with the “correct” structure (including the root statuses array and the workflow version object), the API is extremely sensitive to read-only fields. The Current Blocker : Despite matching the JSON structure seen in the browser’s developer tools, I am consistently receiving: {“errorMessages”:[“Other workflow updates are in progress. Check the workflow editor…”]} This occurs even when no one is editing the workflow and all drafts have been discarded/published. Current Payload Snippet -JSON: { “ruleKey”: “forge:expression-validator”, “parameters”: { “key”: “ari:cloud:ecosystem::extension/…/static/ps-workflow-extention-linkedissue-validator”, “id”: “NEW_UUID”, “config”: “” } } Any advice from developers who have successfully automated Forge rule injection would be a lifesaver! 1 post - 1 participant Read full topic

ECOHELP ticket access issue Hello, I have submitted an app for review, and got this ticket: https://ecosystem.atlassian.net/browse/ECOHELP-121121 However I can not access it, the error is “We can’t show this project. You don’t have permission to view it, or it doesn’t exist. Contact your admin to request access.“. I have clicked the “Request access” button, first about 4 days ago, but nothing changed. Could some please help me solve this? My email is gabor.vitez@gmail.com (AdminHelm). Thank you! 1 post - 1 participant Read full topic

How Amdahl’s Law still applies to modern-day AI inefficiencies Across industries, leaders are rushing to add AI to everyday work. Developers now push code in hours, writers shape first drafts before meetings, and analysts spin up models by lunch. It all looks like a wave of productivity on the surface. However, Amdahl’s Law offers a quiet warning underneath that wave. In any system, the maximum speedup islimited by the slowest process in the workflow. If you only accelerate one slice of the work, the rest of the workflow sets a hard ceiling on how fast the whole thing can go. Right now, AI is mostly speeding up individual work: drafting, coding, and analysis. Yet on most teams, those activities make up only a fraction of the lifecycle. The bulk of the time is still spent on human collaboration and process: reviews, decisions, sign‑offs, risk checks, and alignment across teams. That means there’s a built‑in cap on how much faster AI alone can make the system, if we only look at increasing efficiency of individuals. We are currently witnessing a 43% gap between ‘felt’ speed and actual output, where individual efficiency gains are being swallowed by the friction of team-level handoffs. Team-level velocity charts stay flat, cycle times refuse to budge, and people feel more stretched instead of relieved. That is the AI efficiency paradox. AI can make an individual much faster, but unless we redesign the way teams work, the gains leak out through handoffs, reviews, and decisions long before they reach customers. Engineering teams were early adopters of AI, so we can see this paradox most clearly in the software development lifecycle. While the same pattern shows up across modern organisations, this article will focus on examples from software development and software systems. Amdahl’s Law for teams Use Amdahl’s Law to decide where to improve, not just to restate that one slow step can cap the whole system. Let the parts that rarely speed up guide your design of the rest of the workflow, so that human attention is reserved for moments...

What actually changes when AI joins your research process If you’re a PM or PMM, your research cycle probably looks something like this: Interviews and surveys land in a tool like Dovetail You promise yourself you’ll “just take a day” to organize everything A week later, you’re still tagging, finding quotes, and rewriting bullets for a deck By the time your findings are polished enough to share, the moment to act is already closing We recently ran this entire cycle completely asynchronously in a single afternoon, and ended up with an interactive, stakeholder-ready research report. It was all about changing how we spent our time and seeing what actually changes when AI is part of the whole research workflow, from raw interviews to a report that stakeholders will read and trust. The study we ran We ran a research study to talk to customers directly about how they manage work today. We’d already used AI to speed up market research, persona work, and planning from weeks to days. The next test: could we do the same for primary research synthesis, without losing nuance? After speaking to customers, our interview recordings were ready in Dovetail. The strategic context, including our research plan, customer hypotheses, and competitor positioning, was already documented in Confluence. The question wasn’t “Can AI summarize our interviews?” Interviews and handwritten notes housed in Dovetail It was: Can AI help us connect all of this fast enough to inform real decisions, while keeping humans in charge of judgment? Step 1: Connect your research data directly The first unlock was connecting tools instead of copy‑pasting between them. Using the Dovetail MCP server, we let Rovo Dev pull: Full interview transcripts Existing highlights Tags and themes we’d already applied What normally would have been two or three days of transcript review was available in minutes. For teams, this step is simple but important: AI works best when it’s plugged into the system of work you already use . Step 2: Give AI strategic context, not just your transcr...

Errors thrown by the `invokeRemote` function The documentation on invokeRemote https://developer.atlassian.com/platform/forge/apis-reference/ui-api-bridge/invokeRemote/ is pretty sparse of details on the actual errors thrown by the invokeRemote. I would like to categorize errors in: Timeout ( That’s possible, as I get an error with a Remote invocation timed out message) Response size over the limit (I get a generic An error occurred while trying to invoke ) Rate limit hit (I don’t even know how to trigger this) … other unknown error What are my options? 1 post - 1 participant Read full topic

Unexpected response form an Automation action that gets data I have an automation action that uses an endpoint for its execution. The configuration and invocation are working as expected, but the response I see in the automation rule includes the whole endpoint information including headers and status code. When I log the response form my action using a Log Action I see this {success=true, payload={headers={date=[Fri, 03 Apr 2026 10:23:18 GMT], content-type=[application/json], transfer-encoding=[chunked], connection=[close], cache-control=[no-cache, no-store, max-age=0, must-revalidate], expires=[0], pragma=[no-cache], referrer-policy=[origin-when-cross-origin], x-content-type-options=[nosniff], x-xss-protection=[0], cf-cache-status=[DYNAMIC], nel=[{"report_to":"cf-nel","success_fraction":0.0,"max_age":604800}], report-to=[{"group":"cf-nel","max_age":604800,"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=KOqlJcoaqmJuW%2BzdNnoyBvrtibNugIcdhPLeXn4yYFq%2FEWm%2FRfD4c%2BmQdIii5lkZ8%2BXOtAIujAQMCiEGzvyfpFx70899IQKujls%2F%2F5Pt1ncsAuwdhYnR74HdslApnJc0xp2ZvCJjL1%2BRK1E%3D"}]}], content-encoding=[gzip], server=[cloudflare], cf-ray=[9e675b5b0cf71625-IAD], alt-svc=[h3=":443"; ma=86400]}, status=200, body=....} Where I would only expect the contents of the body field. Now to use the content of the action I need to select it using {{fetchedJenkinsJobList.payload.body}} instead of {{fetchedJenkinsJobList}} to access the response from the action. This response also makes no sense when looking at the outputContext and outputs I need to configure for the action in the manifest. Any specific reason the action using an endpoint is behaving this way that doesn’t match the documentation? @JakubMierzewski I know you moved on to other parts of the code base, but as PM of the EAP do you know? Or know who to contact about this? 1 post - 1 participant Read full topic

Introducing: Final Steps in Bitbucket Pipelines If you’ve ever run a pipeline, you’ve certainly encountered the following situation: The pipeline fails halfway through, and the cleanup script you needed at the end to tear down test infrastructure or archive the logs never gets to run. Until now, there was no built-in way in Bitbucket Pipelines to guarantee that a step always executes at the end of your pipeline, regardless of what happened before it. Today, we’re fixing that. We’re introducing final steps : a new step in Bitbucket Pipelines that lets you define “always-run” logic directly in your bitbucket-pipelines.yml . Cleanup, telemetry, notifications, audit events — the final step always runs, ensuring whatever you needed to happen at the end, always happens. How to use the Final Step The final step is a special construct in Bitbucket Pipelines that: Runs after all other steps in a pipeline. Executes regardless of the outcome of previous steps (failed, passed, skipped, or stopped). Runs again on re-runs, resumes, and redeploys . Is clearly marked in the Pipelines UI as the final step. Behaves like a regular step, with a few targeted restrictions to keep pipelines predictable. To use it, just add a final: section as the last entry in your pipeline definition: pipelines: default: - step: name: Build & Test script: - echo "This is the build step" - step: name: Deploy script: - echo "This is the deployment step" - final: name: Cleanup script: - echo "This is the final step" What happens? The final step always runs last, even if earlier steps fail or are skipped. In the UI, it’s visually identified as the final step for quick visibility. Real word examples In this example, the final step runs regardless of whether the build or deploy steps pass or fail: pipelines: default: - step: name: Build & Test script: - echo "This is the build step" - exit 1 # simulate a failure - step: name: Deploy script: - echo "This is the deployment step" - final: name: Cleanup script: - echo "This is the final step" You can also defin...

Auto-complete your backlog. Unleash your favorite AI models with deep context, from plan to code, with Rovo Dev in Jira Rovo Dev , Atlassian’s context-aware AI agent for software teams, is now directly available inside Jira so simpler, repetitive work can move from task item to merge-ready PR in the background while your team stays focused on the hard problems. Completing Jira work without breaking focus Most development work already begins in Jira as a task, a bug, an idea. But the actual coding? That happens somewhere else. Developers instinctively reach for an IDE or CLI for every task. They bounce between tools when taking an idea through to deployment, searching for context and manually tracking work across tools, branches, pipelines, and PRs. With every tab switch, important context is lost and time is spent regaining focus. Not every task needs this much overhead. Some work is strategic and demands deep design and engineering time. But others, like resolving security vulnerabilities, cleaning up stale feature flags, and fixing minor bugs, are repetitive and well understood. What if developers could delegate those routine tasks to an AI agent that understands their work? We’re meeting development teams where they already plan and track work by making Rovo Dev available directly inside Jira. And because Jira holds the requirements and context behind what teams intend to get done, Rovo Dev can autonomously handle tasks along the software development lifecycle. Developers stay in the driver’s seat, choosing what to delegate versus tackle themselves, reviewing plans and progress, and approving changes before anything ships. The result is more merge-ready PRs with less boilerplate and context‑switching, and an AI teammate that helps your whole team move faster on real Jira work. Rovo Dev takes on the work that slows you down Rovo Dev in Jira turns your Jira work items into an AI-powered execution surface. You can spin up and orchestrate multiple Rovo Dev sessions in the cloud from any Jira work item. Rovo Dev gathers the right context, proposes a concrete plan you can review and ref...

Introducing the Bamboo to Bitbucket Pipelines migration tool (Beta) With the Bamboo Data Center End of Life (EOL) scheduled for March 28, 2029, many teams are already mapping out their long-term journey to the cloud. While 2029 provides a comfortable runway, we want to make sure we offer the right bridge when you’re ready to migrate. Moving your critical CI/CD workflows from Bamboo to the cloud shouldn’t feel overwhelming. To make this move smoother, we’ve built the Bamboo to Bitbucket Pipelines migration tool to take on the hard parts of migration for you. Paired with our comprehensive migration guide , the tool streamlines the entire process from Bamboo to Bitbucket Pipelines, making it easier, faster, and more efficient. Why migrating to Bitbucket Pipelines? Migrating to Bitbucket Pipelines means less time managing infrastructure and more time doing what you love: building incredible software. Bitbucket Pipelines brings a fully managed, cloud-based platform designed around your team’s productivity: Zero wait times for your developers: Instant, elastic scaling eliminates the bottlenecks of fixed on-prem build agents. Your builds start when your team needs them. Massive reduction in operational overhead: No more time spent maintaining hardware, patching vulnerabilities, or running CI server upgrades. Lower costs: We’ve seen teams reduce their total cost of ownership by up to 70% at scale by eliminating on-prem operational overhead. Effortless compliance: Organization-level orchestration ensures governance standards are met across every repository, without slowing developers down. How does the tool work? The Bamboo migration tool is included as part of the Bitbucket Pipelines Importer , a CLI you can run wherever you work—locally, in CI, or in any environment you operate—to bring the automation you need for running migrations at scale. It converts your Bamboo YAML plans into Bitbucket Pipelines syntax while respecting your unique configurations. Here are the key features supported: Pre-migration audit: The audit command scans your B...

Agent Context Pruning: How Rovo Dev keeps long sessions useful In one sentence Agent context pruning is how Rovo Dev keeps long-running coding sessions useful by removing the least valuable context first, preserving the most important parts of the conversation, and only collapsing to a summary when necessary. AI agents become more useful as they work through longer tasks. But longer tasks also create a memory problem. A serious coding agent accumulates a growing trail of context: user requests, assistant responses, tool arguments, tool results, file contents, search results, workspace views, and intermediate reasoning steps. Over time, that history can become large enough to crowd out the context that actually matters for the next decision. That is where context pruning comes in. In Rovo Dev, pruning is the mechanism that maintains long sessions inside the model’s working memory by compacting the least valuable context first – without throwing away the conversation wholesale. Why pruning matters Language models have a limited context window. Once a session gets large enough, one of two problems occurs: the model can no longer fit all relevant history and starts losing important context; or interactions suffer from an increasing tax in tokens, latency, and degraded reasoning quality. This gets especially acute for coding agents, because they tend to generate and consume large amounts of machine-produced text. A single session may include huge tool outputs, repeated file views, and multiple intermediate tool-calling steps that were useful in the moment but are not equally valuable forever. The key idea Not all context is equally valuable. A long tool result from 40 interactions ago is usually much safer to trim than the user’s most recent request or the original setup for the task. Pruning is not just summarization When people hear “context management”, they often jump straight to summarization. Summaries are useful, but they are not the first tool we reach for. Our goal is to preserve as much of the original conversation as poss...

MCP Compression: Preventing tool bloat in AI agents Announcing mcp-compressor: reduce MCP tool token usage by up to 97% MCP servers can be extremely token-hungry — a single large server can consume 10,000–17,000+ tokens of context per request just for tool descriptions. mcp-compressor is an open-source MCP proxy from Atlassian Labs that wraps any existing MCP server and reduces its tool-description overhead by 70–97% , without changing how the agent calls tools. Drop it in front of any MCP server in your mcp.json — no changes to the server or the agent required. Model Context Protocol (MCP) has made it dramatically easier to connect LLM agents to real tools. The trade-off is that every MCP server tends to bring along a large bundle of tool descriptions and schemas, and those tokens are expensive. In Rovo Dev , we found that if you simply expose every tool from every server directly to the model, you can spend a surprisingly large fraction of your prompt budget on tool metadata before the model has even started solving the user’s problem. That pushed us toward a simple question: can we preserve the full power of MCP tool calling while paying much less of the upfront token tax? Our answer is tool compression : instead of surfacing dozens or hundreds of full tool definitions to the model, we replace an MCP server’s toolset with a tiny proxy interface that lets the agent discover details on demand. in one sentence Rovo Dev compresses large MCP toolsets into a small, cache-friendly wrapper interface, then expands individual tool schemas only when the model actually needs them. Why this matters As MCP adoption grows, the number of tools available to an agent grows with it. That is great for capability, but expensive for context. For example: The official Atlassian MCP server consuming roughly 10k tokens for Jira and Confluence tools alone. The official GitHub MCP server exposing 94 tools and consuming roughly 17.6k tokens . If you combine several large MCP servers, it becomes easy to spend 30k+ tokens on tool descriptions ...

Delivering 120 PRs in two weeks with Rovo Dev in Jira I’ve had a pretty good experience with our Rovo Dev in Jira solution in the past few weeks. I estimate that I do probably 95% or more of my dev work in it nowadays. I found it super helpful to delegate low to medium complexity tasks to the coding agent while I do something else that needs more of my attention. I managed to get through a large chunk of our RtB backlog for one of our internal services, raise PRs in repositories I don’t usually work in, and started iterating on more side project style work again to improve developer productivity. Scale Rovo Dev in Jira helped me open and merge over a hundred pull requests in just a couple of weeks, allowing me to focus more on feature rollouts and breaking down work for agents to go off coding. I was always into multitasking and juggling multiple branches while waiting on CI runs or kicking feature flag rollouts along, but offloading it from my machine to the remote sandboxes unlocked a new level of productivity for me. When a new bugfix or minor feature request arrives on our internal support Slack channel, I can now immediately act on it instead of sending it into the backlog where it needs to compete with months of other accumulated tasks. This was great for addressing minor papercuts quickly. Capturing a bit of context from a Slack conversation quickly into a Jira work item lets me have a reference to the work that needs to be done, and it gives me an issue key to commit against. Once I have the work item ready, I can kick off an agent session on the work item view using the Generate code with Rovo Dev panel. I just need to select the repository (unless it figures it out automatically), add a bit of extra context in the prompt if needed or if I want to start with part of the solution only, then let the agent do its work in the background. I can now navigate away and move on to other things I need to deal with. When the agent is ready, I’ll get some in-app notifications (and Slack) that I have work ready to review. ...

Products

Announcing the Next Chapter for Bitbucket Pipelines Runners In December 2025, we announced our intention to introduce pricing for self-hosted runners so we could provide stronger support and keep investing in new features and ongoing improvements. You’ve told us that having a free option is important. As a result, we’re introducing a new operating model that lets you continue using self‑hosted runners for free with the option to upgrade to a paid premium runners tier as your needs grow. What does this mean for you? We’ll continue to offer a free tier that is perfect for small to medium teams, up to 100 basic runners per workspace. For teams who need more, we are introducing a new Premium runners offering, that is ideal for teams with complex workloads, higher scale, or compliance needs. This offering will unlock advanced orchestration, higher limits, premium support. Previously, customers paid $15 per concurrent-build per-month based on their Workspace’s maximum concurrent builds (managed by the workspace concurrency limit). Our billing model will be changed to reflect the maximum concurrent build slots actually used by runners each month, while the workspace concurrency limit will serve as a control to cap billing and manage queue behaviour. This change is aimed at improving the flexibility of our pricing model to better reflect real customer usage. You will be able to upgrade your workspace to premium runners at any time. Depending on your current runners setup, your workspace may be migrated with premium runners enabled by default, see the “Migration Scenarios” table below for more information. Changes will be reflected in your monthly billing , and charged by month. Migration & transition details: Action required In line with the original announcement , on June 3, 2026 we will release a new runner version that includes system updates, patches, and security fixes. This will be the upgrade path for both free and premium runners . Steps that require premium features will run only in workspaces where premium runners are enab...

Introducing Flaky Test Detection in Bitbucket Tests Ship faster with signal, not noise Bitbucket Tests now automatically detects and quarantines flaky tests, cutting CI noise so your team can ship faster with confidence. Flaky tests erode trust in your pipeline, waste CI minutes, and slow down deployments. What if your CI could spot and silence them automatically? In January, we launched Tests in Bitbucket Pipelines —a new way to track, organize, and optimize tests right where your builds run. For the first time, teams could see test health over time, drill into failures, and quarantine noisy tests—all within their repo. It was a big step forward. But manually triaging flaky tests across thousands of cases doesn’t scale. Enter Automatic Flaky Test Detection. Bitbucket now flags flaky tests automatically , so you spend less time firefighting and more time delivery customer value. With auto-quarantine, flaky failures stop blocking your builds the moment they’re caught. What’s new: Flaky Test Detection, built-in Building on the foundation of Bitbucket Tests , Bitbucket now automatically scans your test results and flags flaky tests —no extra scripts, plugins, or dashboards required. Just run your pipelines as usual, and Bitbucket does the rest: Spot flaky tests instantly: Bitbucket analyzes your test history and highlights unstable tests right in the UI. Keep your builds clean: Optionally, let Bitbucket auto-quarantine the noisiest tests so they stop blocking your team. Stay in control: Override any test’s status or execution strategy with a click. Why it matters Recent 2026 benchmarks published by Testdino reveal that 84% of pass-to-fail transitions in large-scale CI pipelines are caused by flakiness, while 30% to 60% of all full pipeline runs can fail due to this issue. Beyond compute costs, these tests incur high productivity losses—at Atlassian alone, an engineering analysis estimates 150,000 developer hours are wasted annually investigating flaky failures in a single major repository. Debug Faster : Stop chasing gh...