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

org.jenkinsci.plugins.github_branch_source.ForkPullRequestDiscoveryTrait and com.cloudbees.jenkins.plugins.bitbucket.ForkPullRequestDiscoveryTrait should be able to have the sam @symbol name


    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • structs-plugin
    • None


      So https://github.com/jenkinsci/scm-api-plugin/blob/5b5e58e70489167414b77fd1a7e8a92bf7b3e68e/src/main/java/jenkins/scm/api/trait/SCMTraitDescriptor.java#L84 gives us the knowledge that https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/9296189af7bab5c33ce09f17c66bfda70f7e2c2b/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/ForkPullRequestDiscoveryTrait.java#L184 means to never offer com.cloudbees.jenkins.plugins.bitbucket.ForkPullRequestDiscoveryTrait to any other SCMSource

      So in theory we could put @Symbol("discoverForkPRs") or similar on

      However, if we do that, then the Symbol tooling throws its hands up in the air because all it does is look up the SCMTrait base class implementations and it would find two of them with the same name and throw its hands up in the air saying "I just don't care: use the full class name or go home"

      It should be possible to enhance symbol support somehow to allow either:

      • symbol libraries to solve the contextualization themselves (sounds like funky stuff using reflection on parameterised types); or
      • symbol libraries would have a registry of context filters... and then scm-api could provide a context filter for traits that would use the scm-api specific information to narrow the list... and then much like The Highlander: There would be only one... and all will be right with the world again.

      Also abayer is lazy and should have written this up himself

            Unassigned Unassigned
            stephenconnolly Stephen Connolly
            1 Vote for this issue
            3 Start watching this issue