[JENKINS-70594] Bitbucket Branch Source repository change should require acknowledgement #711
Description
Changing the repository targeted by a Bitbucket Branch source inside of a Multibranch Pipeline Job wipes out the existing branch/PR jobs and their history, and assuming the skip the initial build on a found branch option is not enabled, may trigger many jobs depending on the branch name filter. This is expected behavior, but can be disastrous if the change is unintentional and the effects are unanticipated.
Unintentional changes to the repo name can happen for a number of reasons:
- Accidental click to either the Credentials, Owner, or Repository name
- Credential password change or lockout, resulting in an authentication failure to the Owner
- Repository permissions change
- User has permissions to configure the job, but does not have permissions to view/use the credential that the job is using
Some of these scenarios may display warnings under the Credentials text box, but this can be easily missed if the user is making changes to a different section of the configuration. None of these scenarios require any acknowledgement that the repository has changed before the user can save/apply the change.
This has caused, on numerous occasions in my organization, existing jobs to be wiped out and dozens of new jobs to be triggered simultaneously. This is a confusing and difficult to identify problem for users unfamiliar with the effects of a repository change, did not intend to make such a change, and did not receive any indication that the change occurred.
Originally reported by jpode16, imported from: Bitbucket Branch Source repository change should require acknowledgement
- status: Open
- priority: Trivial
- component(s): cloudbees-folder-plugin
- label(s): user-experience
- resolution: Unresolved
- votes: 0
- watchers: 3
- imported: 20251211-141027
Raw content of original issue
Changing the repository targeted by a Bitbucket Branch source inside of a Multibranch Pipeline Job wipes out the existing branch/PR jobs and their history, and assuming the skip the initial build on a found branch option is not enabled, may trigger many jobs depending on the branch name filter. This is expected behavior, but can be disastrous if the change is unintentional and the effects are unanticipated.
Unintentional changes to the repo name can happen for a number of reasons:
- Accidental click to either the Credentials, Owner, or Repository name
- Credential password change or lockout, resulting in an authentication failure to the Owner
- Repository permissions change
- User has permissions to configure the job, but does not have permissions to view/use the credential that the job is using
Some of these scenarios may display warnings under the Credentials text box, but this can be easily missed if the user is making changes to a different section of the configuration. None of these scenarios require any acknowledgement that the repository has changed before the user can save/apply the change.
This has caused, on numerous occasions in my organization, existing jobs to be wiped out and dozens of new jobs to be triggered simultaneously. This is a confusing and difficult to identify problem for users unfamiliar with the effects of a repository change, did not intend to make such a change, and did not receive any indication that the change occurred.
- environment:
Jenkins: 2.346