bitbucket CI tests failing

bitbucket CI tests failing

These four failures are all HTTP 410 Gone against https://bitbucket.org/isomorphic-git/test.empty, returned by Bitbucket itself when the test authenticates with an App Password. Bitbucket announced this 12 months ago. Quoting from Atlassian's own Bitbucket Cloud app password brownout schedule:

Effective: June 9, 2026 In the final weeks of support for app passwords, we will run a series of brownouts from June 9, 2026 to July 27, 2026… During each brownout window:

All API requests authenticated using app passwords will fail with an HTTP 401 error code All Git-over-HTTPS operations authenticated using app passwords will fail with an HTTP 410 error code Phase 2: End of life of app passwords — Effective: July 28, 2026 App password authentication will be permanently disabled and will return errors.

The CI logs you shared show the failure at 2026-06-09T18:07Z — which is today, the first day of brownouts. Today's date in the workspace context is also Jun 9, 2026. That timing isn't a coincidence.

So the chain of evidence is:

The failing tests are exactly Hosting Providers › Bitbucket › push and Hosting Providers › Bitbucket › fetch, both in tests/test-hosting-providers.js and tests/test-hosting-providers-in-submodule.js. They use a hardcoded App Password (reverse('TqSWhF3xLxEEXKQtZTwn')) at the time of the deprecation:

test-hosting-providers.js Lines 108-109 const password = reverse('TqSWhF3xLxEEXKQtZTwn') const username = 'isomorphic-git' The remote URL is the real Bitbucket repo:

config Lines 19-21 [remote "bitbucket"] url = https://bitbucket.org/isomorphic-git/test.empty fetch = +refs/heads/:refs/remotes/origin/ The error class — exactly HTTP 410 Gone — is the specific code Atlassian documented for app-password Git-over-HTTPS during the brownouts. They wouldn't normally use 410 for a Git endpoint; it's intentionally chosen to be a flag, not a generic failure. The same 4 tests fail on every retry, identically. A flaky network would be intermittent. So: not your bug, not the branch's bug, not a transient blip. Atlassian intentionally turned off app-password Git auth for a window today. It will be intermittent until July 27 (each brownout window) and then permanent on July 28.

Two reasonable paths forward

Path 1 — quick: skip the Bitbucket tests for now

There's already precedent in this very file: the GitLab block uses xdescribe (line 200), presumably because GitLab made an analogous change earlier. We can do the same to the Bitbucket block:

describe('Bitbucket', () => { // App passwords were deprecated by Atlassian in 2025 and enter // permanent removal on July 28, 2026, with brownouts beginning // June 9, 2026 (Atlassian community post 3237429). Until the test // is migrated to an API token, the Git-over-HTTPS calls return // HTTP 410 Gone during brownouts and HTTP 401/410 thereafter. xdescribe('Bitbucket', () => { …in both tests/test-hosting-providers.js and tests/test-hosting-providers-in-submodule.js. That's it. Effect: 4 fewer Ubuntu failures, no other change anywhere.

This is a 2-line change per file. It immediately unblocks every PR's CI and matches what was already done for GitLab. It also makes the suite pass cleanly today on Linux, leaving your Windows-fix work cleanly evaluable.

Path 2 — proper: migrate to an Atlassian API token

The longer-term fix per Atlassian's own guidance is:

Create an Atlassian API token at id.atlassian.com/manage-profile/security/api-tokens with scopes read:repository:bitbucket and write:repository:bitbucket. Store it as a GitHub Actions secret (analogous to TEST_PUSH_GITHUB_TOKEN, e.g. TEST_PUSH_BITBUCKET_API_TOKEN). Update the test to read the token from process.env, skip-with-warning if absent (mirroring the GitHub pattern at lines 147–153), and use either the bitbucket username or the static x-bitbucket-api-token-auth username for Git operations. This is more work and requires the maintainer to configure the secret on the repo (an isomorphic-git-org admin task; you can't do it from a fork).