单分支Pipeline正常，同项目多分支Pipeline凭证问题咨询

Let’s break down why your multi-branch Pipeline is failing to pull the Jenkinsfile from Bitbucket (even though your single-branch setup works perfectly) and the core differences in how they handle credentials:

1. Credential Resolution & Scope #

• Single-branch Pipeline: This setup uses a straightforward, direct approach. When you configure the repository URL with an embedded username (like https://Username@bitbucket.org/myproject.git), Jenkins will directly look for a matching credential (username + password/app password) in its global or project-specific store to fill in the missing auth details. It’s a one-off git clone operation tied strictly to your explicit project config.
• Multi-branch Pipeline: This relies on the Branch Source plugin (e.g., Bitbucket Branch Source) to scan and manage all branches. Its credential logic is far stricter:
  • It doesn’t parse the username from the repository URL you enter. Instead, it expects you to select a pre-configured credential from Jenkins’ store that’s compatible with both Bitbucket’s API and git operations.
  • If the credential isn’t properly linked in the branch source settings, or if it lacks permissions to list all branches (not just clone a single one), Jenkins can’t auto-resolve the auth. This leads to the terminal prompts disabled error—since it can’t prompt for a password interactively during the automated branch scanning process.

2. Jenkinsfile Retrieval Flow #

• Single-branch: The Jenkinsfile path is fixed in your project config. Jenkins pulls it immediately using the exact URL and credential you specified, with no pre-scanning steps. It’s a targeted, direct operation.
• Multi-branch: Before pulling any Jenkinsfile, the plugin first hits the Bitbucket API to discover all available branches. For each branch found, it then attempts to pull the Jenkinsfile. This two-step process requires the credential to have both API access (to list branches) and git clone permissions—something your single-branch setup might not need, since you’re only targeting one branch directly.

3. Credential Type Compatibility #

• Single-branch: Works well with basic "Username with password" credentials, even if you embed the username in the URL. It’s flexible about credential types as long as git can use them for cloning.
• Multi-branch: The Bitbucket Branch Source plugin prefers Bitbucket-specific credential types (like "Bitbucket Cloud Credentials") over generic HTTPS credentials. Generic credentials might fail here because the plugin needs to interact with Bitbucket’s REST API to fetch branch metadata—not just perform a git clone. Using Bitbucket’s app passwords (instead of your account’s main password) is also critical here, as Bitbucket no longer supports using account passwords for git HTTPS operations.

Quick Fixes for Your HTTPS Issue #

1. Remove the username from your repository URL: In the multi-branch project’s branch source settings, use https://bitbucket.org/myproject.git instead of embedding the username. Let Jenkins handle auth via the selected credential.
2. Use a Bitbucket-compatible credential: Create a "Bitbucket Cloud Credential" in Jenkins using your Bitbucket username and an app password (generate one in Bitbucket’s account settings with repo read permissions).
3. Verify credential permissions: Ensure the app password has permission to read the repository and list its branches.

For the SSH Problem (Single-Branch Failure) #

If SSH isn’t working even for single-branch pipelines, check these:

• The Jenkins server’s system user (e.g., jenkins) has an SSH private key in ~/.ssh/id_rsa (or the path you specified) with strict permissions (chmod 600 for the private key, chmod 644 for the public key).
• The corresponding public key is added to your Bitbucket account’s SSH keys or the repository’s access keys.
• You’re using the correct SSH URL (git@bitbucket.org:myproject.git) in your Jenkins config, and the credential is set up as an SSH username with private key.

内容的提问来源于stack exchange，提问作者Rob The Ranger