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

Allow SCMSource and SCMNavigator subtypes to share common traits

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Examples of traits from the JENKINS-43426 epic:

      • There will be a strategy to use switch the checkout to over SSH and this will have a option to select the SSH Credentials for checkout.
      • There will be at least one strategy to subset the branches by name (include / exclude)
        • There will one implementation that uses the existing wildcard style
        • Other strategies may be added later to support different branch name matching rules, e.g. Regex, etc. These secondary strategies do not form part of the MVP but it may prove assist extension point API validation to proof-of-concept implement a second one.
      • There will be three strategies to subset the branches by type:
        • There will be a strategy to select origin branches. This strategy will have a drop-down mode selection:
          • Only origin branches that are not filed as PRs
          • Only origin branches that are filed as PRs
          • All origin branches irrespective of whether filed as PR or not
        • There will be a strategy to select origin PRs. This strategy will have a drop-down mode selection:
          • Merge commit PRs
          • Head commit PRs
          • Both merge commit and head commit PRs
        • There will be a strategy to select fork PRs. This strategy will have a drop-down mode selection:
          • Merge commit PRs
          • Head commit PRs
          • Both merge commit and head commit PRs
      • There will also be a drop-down for trust selection:
          • Show all fork PRs but only trust fork PRs from repository contributors
          • Only show PRs from repository contributors
          • Show and trust all fork PRs
             TBD determine if we need to expose suppression of automatic builds of untrusted PRs here.
        • There will be a proof-of-concept implementation of a tag support branch selector. This is not a feature experienced by users today, but there are api's & code which is ready to provide it. We won't ship this enabled by default in the release.
      • There will be the ability to control a subset of the Git plugin’s additional behaviours for the generated SCM of branches. This will be an applies to all setting. The available options will be subject to a whitelisting extension point (so that plugins can define additional Git behaviours and whitelist them in at the same time). The default whitelist will be:
        • Advanced Checkout behaviours
        • Advanced Clone behaviours
        • Advanced Submodule behaviours
        • Clean after checkout
        • Clean before checkout
        • Custom user name / email address
        • Git LFS pull after checkout
        • Use commit author in changelog (says it requires workspace polling, but really does not / should not require workspace polling)
        • Wipe out repository & force clone

      Acceptance criteria

      • The SCM API provides the concept of a trait that applies to SCMSource and SCMNavigator
      • Traits will be opt-in, i.e. the SCMSource implementation must be written to use traits
      • Common trait implementations can be shared by multiple implementations.
      • Trait implementations can be specific to a single SCMSource or SCMNavigator
      • The SCM API will provide a trait implementation that allows for filtering branches based on include/exclude wildcard name matching
      • The SCM API MockSCM implementation will support traits
      • The common trait implementations in SCM API will have tests
      • The implementers guide will be updated to highlight the trait style of implementation and encourage following that path. 

        Attachments

        1. advanced.png
          99 kB
          Stephen Connolly
        2. after-adding-advanced.png
          308 kB
          Stephen Connolly
        3. before-adding-advanced.png
          229 kB
          Stephen Connolly
        4. Screen Shot 2017-07-31 at 10.54.25.png
          303 kB
          Stephen Connolly

          Issue Links

            Activity

            Hide
            stephenconnolly Stephen Connolly added a comment -

            Ludovic Mercier are you trying to build tags or are you trying to compare against tags?

            If building tags, this is not yet supported (may have accidentally worked previously, but was not intended to work)

            If comparing against tags, have you done a reindex first to update all the job configurations?

            Show
            stephenconnolly Stephen Connolly added a comment - Ludovic Mercier are you trying to build tags or are you trying to compare against tags? If building tags, this is not yet supported (may have accidentally worked previously, but was not intended to work) If comparing against tags, have you done a reindex first to update all the job configurations?
            Hide
            ludovic_mercier Ludovic Mercier added a comment -

            Hi Stephen Connolly,

            Thanks for your time, We were building tags effectively and i must say it's not a good news to read that it shouldn't have worked.

            It seems that we will have to change our strategy and workflow according to this or maybe you have a potential roadmap about this feature.

            Show
            ludovic_mercier Ludovic Mercier added a comment - Hi Stephen Connolly , Thanks for your time, We were building tags effectively and i must say it's not a good news to read that it shouldn't have worked. It seems that we will have to change our strategy and workflow according to this or maybe you have a potential roadmap about this feature.
            Hide
            stephenconnolly Stephen Connolly added a comment -

            Ludovic Mercier so there are issues with building tags that need to be addressed: 

            • We probably want the concept of interesting heads: JENKINS-45502
              • Old tags are not interesting for sure
              • New tags might be interesting if the user wants to configure it that way
            • Interesting heads is not strictly required for branch-api as there is the ability to define a BranchBuildStrategy and that would allow suppressing automatic builds of tags on project creation (which is really the big issue for tags)
            • Support for implementing tags in the GitHub plugin is being tracked in JENKINS-34395, likely we'll just consolidate the Bitbucket, Git and Gitea implementations of the same feature under this banner 

            HTH

            Show
            stephenconnolly Stephen Connolly added a comment - Ludovic Mercier so there are issues with building tags that need to be addressed:  We probably want the concept of interesting heads: JENKINS-45502 Old tags are not interesting for sure New tags might be interesting if the user wants to configure it that way Interesting heads is not strictly required for branch-api as there is the ability to define a BranchBuildStrategy  and that would allow suppressing automatic builds of tags on project creation (which is really the big issue for tags) Support for implementing tags in the GitHub plugin is being tracked in  JENKINS-34395 , likely we'll just consolidate the Bitbucket, Git and Gitea implementations of the same feature under this banner  HTH
            Hide
            stephenconnolly Stephen Connolly added a comment -

            Riko Eksteen

             it is listed in the JIRA properties as a "minor" change

            Nope, it was listed as a PRIORITY of "minor", not a scope.

            The refactoring itself is binary compatible but adds new methods. There are extensive tests of data migration. I believe there is only one use case where we missed a potentially breaking change, namely if you construct the SCMSource instance in your pipeline directly (e.g. for use with resolveScm) in all other cases the existing configuration should have been migrated:

            If you have a migration data set that is not migrating correctly, then that is a bug which should be filed in a separate JIRA and we can add an additional test case for your configuration and then fix it

             

            Show
            stephenconnolly Stephen Connolly added a comment - Riko Eksteen  it is listed in the JIRA properties as a "minor" change Nope, it was listed as a PRIORITY of "minor", not a scope. The refactoring itself is binary compatible but adds new methods. There are extensive tests of data migration. I believe there is only one use case where we missed a potentially breaking change, namely if you construct the SCMSource instance in your pipeline directly (e.g. for use with resolveScm ) in all other cases the existing configuration should have been migrated: https://github.com/jenkinsci/github-branch-source-plugin/blob/f2a9fdd871e218429cd1de198b130596e90ee167/src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceTraitsTest.java#L107-L396  and https://github.com/jenkinsci/github-branch-source-plugin/blob/f2a9fdd871e218429cd1de198b130596e90ee167/src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSourceTraitsTest.java#L800-L1997   https://github.com/jenkinsci/github-branch-source-plugin/blob/f2a9fdd871e218429cd1de198b130596e90ee167/src/test/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMNavigatorTraitsTest.java#L58-L1561 https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/master/src/test/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketSCMSourceTest.java#L57-L434 https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/e220b43404aca15574c7a9be3724a40587093414/src/test/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketSCMNavigatorTest.java#L53-L461 https://github.com/jenkinsci/git-plugin/blob/e08051a8e571f32887d463c72361123b6b37befb/src/test/java/jenkins/plugins/git/GitSCMSourceTraitsTest.java#L81-L211 If you have a migration data set that is not migrating correctly, then that is a bug which should be filed in a separate JIRA and we can add an additional test case for your configuration and then fix it  
            Hide
            gregcovertsmith Greg Smith added a comment -

            Wanted to follow up, and say that once that once we completed a full rescan of our org, the additional behaviors were copied down to each project, and the original behaviors were restored.  This resolved all of our problems.

            Several of the other featured included in this change are very handy, so I wanted to say thanks again, I think this change overall will be be very useful in the long term. 

            Show
            gregcovertsmith Greg Smith added a comment - Wanted to follow up, and say that once that once we completed a full rescan of our org, the additional behaviors were copied down to each project, and the original behaviors were restored.  This resolved all of our problems. Several of the other featured included in this change are very handy, so I wanted to say thanks again, I think this change overall will be be very useful in the long term. 

              People

              • Assignee:
                stephenconnolly Stephen Connolly
                Reporter:
                stephenconnolly Stephen Connolly
              • Votes:
                4 Vote for this issue
                Watchers:
                20 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: