Weekly Bitbucket changelog page in Confluence

By General Input

Every Friday at 4pm, publish a weekly changelog page to Confluence built from the Bitbucket pull requests your team merged that week.

Integrations

  • Bitbucket
  • Confluence

Type

Deterministic Code

Categories

  • Engineering
  • Product

Every Friday at 4pm, publish a weekly changelog page to Confluence built from Bitbucket pull requests merged that week. Use a cron trigger. No AI reasoning is required: the title prefix is the classifier, ordering is by merge date, and the template is fixed. Build this as a deterministic code workflow.

Step 1. List merged pull requests from the configured Bitbucket repository using the Bitbucket List Pull Requests operation. Use a BBQL query of state="MERGED" AND updated_on>="<ISO timestamp for 7 days ago>", sort=-updated_on, and pagelen=50 (that is the max for pull requests). Follow the HAL next link on the response to paginate until there is no next. Pull request state values are uppercase in Bitbucket.

Step 2. Group the returned pull requests by conventional-commit prefix parsed off the PR title. Recognize feat, fix, chore, docs, and refactor. Parse case-insensitively and tolerate an optional scope like feat(api): or fix(ui): — match a leading token of letters, an optional (scope) in parentheses, then a colon. Any PR whose title does not match one of the five known prefixes falls into an Other bucket. Within each group, keep the entries in merge-date order using updated_on descending.

Step 3. Format each entry as "PR title — author (link)". Use the PR's html link from the links.html.href field, and the author display_name. Skip groups that end up empty.

Step 4. Create a new page in Confluence using the Confluence Create Page operation. Title it "Changelog — week of YYYY-MM-DD" where YYYY-MM-DD is the current Friday's date. Set the parentId to the configured parent page and the spaceId to the configured space. Publish the page (not a draft).

The Confluence page body must be Confluence storage format (XHTML-like). Render each non-empty group as an <h2> heading with a friendly label (Features for feat, Fixes for fix, Chores for chore, Docs for docs, Refactor for refactor, Other for the fallback bucket) followed by a <ul> of <li> entries, one per pull request. Each <li> should read: PR title, an em dash, author name, then a link to the PR wrapped in an <a href="...">link</a> tag or similar.

Expose these as configurable inputs: the Bitbucket workspace slug and repository slug, the Confluence cloudId, the target spaceId, the parent page id, and the cron schedule. Everything else — the seven-day window, the prefix list, the classifier logic, the section labels, the page title format, and the storage-format template — is fixed inside the workflow.

Related prompts

Explore more prompts
One inbox for every Jira Service Management approval waiting on youAssign owners to stale Confluence pages, space by spaceSee every open Confluence action item on one boardDocumentation ownership register for your Confluence wikiMerge desk for duplicate and conflicting Confluence pagesTrack who has read every onboarding page in ConfluenceOne review board for every open Bitbucket pull requestSee which sprint tickets actually have code behind themBitbucket build health console for on-call engineersWeekly Statuspage reliability report for leadership