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

Some preexisting Git multibranch project settings don't appear in new UI, even though they're still set

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Not A Defect
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
    • Similar Issues:

      Description

      Summary:
      Given a Git multibranch project with many Additional Behaviours options set, after taking the beta-1 upgrades, some of these behaviors are not shown in the revised UI. So far, the job's config.xml file appears to be unaffected - in other words, the settings which don't show up in config.xml do not appear in the UI.

      Assumptions:
      This issue assumes that project settings which were set in a multibranch job before taking the upgrade, should remain visible to the user after taking the upgrade. Especially those settings which remain present in the job's config.xml file.

      Steps to recreate: This is an example job. There are obviously a great many "additional behaviours" which can be set - 23 options are available in the dropdown, and some of those 23 reveal nested settings.

      1. Set up a Multibranch job, using Git (not GitHub) as your source. I just pointed mine to a GitHub repo that I use frequently, by supplying the same URL that gets supplied by GitHub's "Clone with HTTPS" button.

      2. Under "Additional Behaviours," select "Check out to a specific local branch" and provide an easy to spot branch name. In the examples attached I used FANCY.

      3. Also under "Additional Behaviours," select "Check out to a sub-directory," and provide an easy to spot subdirectory name. In the examples attached I used CheckOutToASubdirectory.

      4. Finally, select "Strategy for choosing what to build," and pick Ancestry. Under this, set Maximum Age of Commit to 10.

      5. Upgrade the plugins to the betas.

      6. Note that this information does not appear in the UI anywhere.

      The question is...should it appear, or is it by design that this information is hidden from view?

      Other notes:
      I've attached four files:

      • before.xml and after.xml: the job xml files, as returned by the Jenkins CLI, before and after taking the plugin upgrades. The files are identical.
      • Git--NOT--GitHubConfigBEFORE.pdf: A PDF of the pre-upgrade config page for the job. (page was too long to screenshot so this was the next best thing)
      • Git--NOT--GitHubConfigAFTER.pdf: A PDF of the post-upgrade config page for the same job.

        Attachments

        1. after.xml
          6 kB
        2. before.xml
          6 kB
        3. Git--NOT--GitHubConfigAFTER.pdf
          129 kB
        4. Git--NOT--GitHubConfigBEFORE.pdf
          121 kB

          Activity

          Hide
          kshultz Karl Shultz added a comment -

          I take that back.

          The acceptance criteria in JENKINS-43426 describes a default subset, via whitelisting, of the Git plugin's additional behaviors. They are as follows:

          • 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

          The before/after shows that these are the ones present. I am thus closing the issue.

          Show
          kshultz Karl Shultz added a comment - I take that back. The acceptance criteria in JENKINS-43426 describes a default subset, via whitelisting, of the Git plugin's additional behaviors. They are as follows: 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 The before/after shows that these are the ones present. I am thus closing the issue.
          Hide
          kshultz Karl Shultz added a comment -

          As described above.

          Show
          kshultz Karl Shultz added a comment - As described above.

            People

            • Assignee:
              stephenconnolly Stephen Connolly
              Reporter:
              kshultz Karl Shultz
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: