Jenkins Bitbucket HTTPS Token Problem

[darren_dickerson]

Hi,

Hope you are doing well.

I am a CICD Noob and I need some help.

I have a Jenkins problem.  I am trying to get that api token thing to work.  No joy. I am putting my owner name and the contents of the api key as user and password.   It works when we are off that brownout.  It used to work all the time.  My Jenkins I let it get old and there are plenty of things to download.  I thought I would start fresh on a new machine so the old one would stay "up."  I can't the old Jenkins server to work all the time.  The new Jenkins not at all. AI is no help.  I don't even know enough to troubleshoot it. My story board and branches all work fine.  Where should I start?

Thanks,
Darren

[Gabriela · Accepted solution]

That "works off the brownout, dies during it" pattern is the giveaway — the credential you've got is still an app password. The brownout only knocks out app passwords (git over HTTPS returns 410 during the windows), so anything that lines up with the brownout exactly is app-password auth. A proper API token rides straight through it. App passwords are gone for good on 28 July, so both Jenkins boxes need a real token before then.

A couple of things usually trip up the token setup —

1. The username. For git over HTTPS with an Atlassian API token it has to be x-bitbucket-api-token-auth (or your Bitbucket username). If you're typing the workspace/owner name there, that's the miss; the token itself goes in the password field.

2. The scope. Mint it at id.atlassian.com > API tokens > Create API token with scopes, tick the Bitbucket app and read:repository (add write:repository if the job pushes). A token with no scope won't clone.

For a CI box a Repository Access Token is cleaner than a personal one — Repository settings > Access tokens > Create, scope Repository read; its git username is the literal x-token-auth.

To pin which side is broken, from a shell run: git clone https://x-bitbucket-api-token-auth:<token>@bitbucket.org/<workspace>/<repo>.git — if that clones but Jenkins still fails it's the username saved in the Jenkins credential, and if the shell clone fails too the token's scope or type is off.

Docs: https://community.atlassian.com/forums/Bitbucket-articles/Deprecation-notice-Bitbucket-Cloud-app-password-brownout/ba-p/3237429

[darren_dickerson]

Thank you for replying!  I am testing this... :D

[darren_dickerson]

My old Jenkins server is running.  The new one, I got further.  I think I am just missing a plugin.  Thanks again!

[Ryan Farnell]

I'm seeing a similar issue. I migrated to API tokens last week and haven't issues until today. Jenkins can do the initial clone but fails to get submodules.

[Gabriela]

Hi @Ryan Farnell, submodules don't inherit the parent clone's credential, so Jenkins fetches them with whatever's saved separately, usually still an app password. That's why it only broke today: the brownout returns 410 for app passwords during its windows, so the main clone rides through on your token while the submodule fetch dies.

In the job's Git configuration, open Additional Behaviours > Advanced sub-modules behaviours and tick "Use credentials from default remote of parent repository" so the submodule fetch reuses the token.

One more to check: a Repository Access Token only covers the single repo it was minted on, so any submodule living in a different repo will 403 even with that box ticked. For cross-repo submodules use a Project or Workspace access token, or a personal API token with read:repository.

From a shell you can confirm it with git config --global url."https://x-token-auth:<token>@bitbucket.org/".insteadOf "https://bitbucket.org/" then git submodule update --init --recursive.