Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-68134

Bitbucket link points to non-existant project on pipeline jobs

      Steps to reproduce:

      • Create a new pipeline project with a Bitbucket SCM. When selecting the project, use a project name instead of a key
      • Save configuration, and click "Browse Repository"

      Expected:
      The action link points to the repository, using the project key and repo name

      Actual:
      The project name is used instead

      This is likely because when the pipeline SCM config is persisted, only the project name is provided from stapler (despite the fact the key is resolved when the project is looked up). This issue is not appearing for multibranch or freestyle jobs. When a build is triggered, the repo is initialized properly, and the issue disappears, so it's not high priority.

      Workaround:
      Kick off a build on the affected, either by webhook or manually.

          [JENKINS-68134] Bitbucket link points to non-existant project on pipeline jobs

          Martin Henschke added a comment - - edited

          This is a regression from the SCM update in 3.1.0, as pipeline repositories are not being resolved until an SCM is created (when the job is run). We do not persist the `projectKey`, despite resolving it on config, so the name is being used to construct the link instead, which will link to the wrong location unless key and name are the same.

          The fix for this requires a change to how project keys are persisted from the SCM. Given that's a more invasive change and the bug has a very easy workaround (and does not appear present in the multibranch pipelines or freestyle as those resolve their SCMs differently), it's probably worth seeing the impact before picking it up.

          Martin Henschke added a comment - - edited This is a regression from the SCM update in 3.1.0, as pipeline repositories are not being resolved until an SCM is created (when the job is run). We do not persist the `projectKey`, despite resolving it on config, so the name is being used to construct the link instead, which will link to the wrong location unless key and name are the same. The fix for this requires a change to how project keys are persisted from the SCM. Given that's a more invasive change and the bug has a very easy workaround (and does not appear present in the multibranch pipelines or freestyle as those resolve their SCMs differently), it's probably worth seeing the impact before picking it up.

            Unassigned Unassigned
            mhenschke_atlassian Martin Henschke
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: