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

Freestyle jobs forgot they have Git as SCM in jenkins 2.269

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      After recently updating to Jenkins 2.265 and later 2.269 I saw a lot of UI issues due to conversion from tables to divs, and among these did not notice that our legacy jobs no longer recognize they have an SCM - although it is there in config.xml on disk. The plugins in our rotation are the newest from download center at the moment (git-4.5.0 in particular), or newer (with yet unreleased fixes for UI applied).

      While pipeline jobs work, the freestyle ones insist that the "Source Code Management" is "None" despite having the tag in config.xml on disk.

      This happens both in Web-UI (where I first assumed this is related to divs-vs-tables migration since that UI is pretty broken at the moment), but also happens when a job config is saved - the tag is lost and replaced on disk by nullSCM (doable by Job Config history reverting to an older config, Extensible Arguments saving a new option value, possibly by editing and saving the config - which was not doable with broken UI, etc.), and what's worse - this happens during run-time parsing of the job to actually run it - git is not called, and jobs fail with no code to build.

      This last point is the show-stopper for many of our infra jobs that were not converted to pipelines due to time or design reasons. For others in these shoes: a temporary workaround for us was to manually check out needed repos into workspaces previously managed and cleaned by Jenkins - now that it thinks there's no git, there's no repo to clean away either.

        Attachments

        1. build-ova.txt
          20 kB
        2. conn-amqp.txt
          14 kB
        3. new-from-scratch.txt
          9 kB

          Activity

          jimklimov Jim Klimov created issue -
          jimklimov Jim Klimov made changes -
          Field Original Value New Value
          Description After recently updating to Jenkins 2.265 and later 2.269 I saw a lot of UI issues due to conversion from tables to divs, and among these did not notice that our legacy jobs no longer recognize they have an SCM - although it is there in config.xml on disk. The plugins in our rotation are the newest from download center at the moment (git-4.5.0 in particular), or newer (with yet unreleased fixes for UI applied).

          While pipeline jobs work, the freestyle ones insist that the "Source Code Management" is "None" despite having the tag in config.xml on disk.
           
          This happens both in Web-UI (where I first assumed this is related to divs-vs-tables migration since that UI is pretty broken at the moment), but also happens when a job config is saved - the tag is lost and replaced on disk by nullSCM (doable by Job Config history reverting to an older config, Extensible Arguments saving a new option value, possibly by editing and saving the config - which was not doable with broken UI, etc.), and what's worse - this happens during run-time parsing of the job to actually run it - git is not called, and jobs fail with no code to build.

          This last point is the show-stopper for many of our infra jobs that were not converted to pipelines due to time or design reasons.
          After recently updating to Jenkins 2.265 and later 2.269 I saw a lot of UI issues due to conversion from tables to divs, and among these did not notice that our legacy jobs no longer recognize they have an SCM - although it is there in config.xml on disk. The plugins in our rotation are the newest from download center at the moment (git-4.5.0 in particular), or newer (with yet unreleased fixes for UI applied).

          While pipeline jobs work, the freestyle ones insist that the "Source Code Management" is "None" despite having the tag in config.xml on disk.
           
          This happens both in Web-UI (where I first assumed this is related to divs-vs-tables migration since that UI is pretty broken at the moment), but also happens when a job config is saved - the tag is lost and replaced on disk by nullSCM (doable by Job Config history reverting to an older config, Extensible Arguments saving a new option value, possibly by editing and saving the config - which was not doable with broken UI, etc.), and what's worse - this happens during run-time parsing of the job to actually run it - git is not called, and jobs fail with no code to build.

          This last point is the show-stopper for many of our infra jobs that were not converted to pipelines due to time or design reasons. For others in these shoes: a temporary workaround for us was to manually check out needed repos into workspaces previously managed and cleaned by Jenkins - now that it thinks there's no git, there's no repo to clean away either.
          Hide
          jimklimov Jim Klimov added a comment -

          Strangely, got a hard time reproducing this... Jobs defined from scratch on a new instance and on the original updated instance behave fine. XML formats seem to be same, except for the git plugin version recorded as last saver (4.4.5, 4.3.0 in older jobs).

          Maybe just defining the SCM values anew, copypasting the settings from config.xml's to UI, would solve this.

          Show
          jimklimov Jim Klimov added a comment - Strangely, got a hard time reproducing this... Jobs defined from scratch on a new instance and on the original updated instance behave fine. XML formats seem to be same, except for the git plugin version recorded as last saver (4.4.5, 4.3.0 in older jobs). Maybe just defining the SCM values anew, copypasting the settings from config.xml's to UI, would solve this.
          Hide
          markewaite Mark Waite added a comment -

          Please provide the XML configuration files of the jobs that are failing so that they can be investigated.

          Show
          markewaite Mark Waite added a comment - Please provide the XML configuration files of the jobs that are failing so that they can be investigated.
          jimklimov Jim Klimov made changes -
          Attachment build-ova.txt [ 53523 ]
          Attachment ci-selftest.txt [ 53524 ]
          Attachment conn-amqp.txt [ 53525 ]
          Attachment new-from-scratch.txt [ 53526 ]
          jimklimov Jim Klimov made changes -
          Attachment build-ova.txt [ 53523 ]
          jimklimov Jim Klimov made changes -
          Attachment build-ova.txt [ 53527 ]
          jimklimov Jim Klimov made changes -
          Attachment ci-selftest.txt [ 53524 ]
          Hide
          jimklimov Jim Klimov added a comment -

          Sure, added minimally redacted copies (any clue or neighboring plugin might matter). The "new-from-scratch.txt" is a config.xml which I configured from scratch and processes SCM properly; 2 other files are various setups that used to work until the upgrade (some using parameterized repo URLs, some verbatim).

          While preparing this sampling, I realized both of the failing items are using several repos and so "multiple-scms" might be the culprit:

          ...
            </properties>
            <scm class="org.jenkinsci.plugins.multiplescms.MultiSCM" plugin="multiple-scms@0.6">
              <scms>
                <hudson.plugins.git.GitSCM plugin="git@4.4.5">
                  <configVersion>2</configVersion>
                  <userRemoteConfigs>
                    <hudson.plugins.git.UserRemoteConfig>
          ...
          

          Both my new test job, and a legacy job defined earlier that I found to re-verify (and seems to still work), used one repo:

          ...
            </properties>
            <scm class="hudson.plugins.git.GitSCM" plugin="git@4.5.1-SNAPSHOT">
              <configVersion>2</configVersion>
              <userRemoteConfigs>
          ...
          

          Pipeline jobs that are configured by one SCM (manually in MultiBranch Pipeline or Organization Folder) and later checkout additional repos from their Jenkinsfile's - these seem to work OK.

          Show
          jimklimov Jim Klimov added a comment - Sure, added minimally redacted copies (any clue or neighboring plugin might matter). The "new-from-scratch.txt" is a config.xml which I configured from scratch and processes SCM properly; 2 other files are various setups that used to work until the upgrade (some using parameterized repo URLs, some verbatim). While preparing this sampling, I realized both of the failing items are using several repos and so "multiple-scms" might be the culprit: ... </properties> <scm class= "org.jenkinsci.plugins.multiplescms.MultiSCM" plugin= "multiple-scms@0.6" > <scms> <hudson.plugins.git.GitSCM plugin= "git@4.4.5" > <configVersion>2</configVersion> <userRemoteConfigs> <hudson.plugins.git.UserRemoteConfig> ... Both my new test job, and a legacy job defined earlier that I found to re-verify (and seems to still work), used one repo: ... </properties> <scm class= "hudson.plugins.git.GitSCM" plugin= "git@4.5.1-SNAPSHOT" > <configVersion>2</configVersion> <userRemoteConfigs> ... Pipeline jobs that are configured by one SCM (manually in MultiBranch Pipeline or Organization Folder) and later checkout additional repos from their Jenkinsfile's - these seem to work OK.
          Hide
          jimklimov Jim Klimov added a comment -

          This investigation pointed me to the fact that our Jenkins did not have the plugin installed. Probably some colleague heeded the warning that it is deprecated and removed it. Installing it back "without restart" did not get the SCMs seen however; will try to Reload config from disk, or will restart Jenkins at night.

          I suppose some safety-belt is needed for these warnings and/or removals, to say that "there are (nontrivial?) configurations (global or in jobs) for a plugin, are you sure you want to remove it?"...

          I see a number of such alerts for warnings-analysis related plugins that are all superseded by one survivor, but I have no idea if people played with them and abandoned, or if some job actually uses them and has to be migrated (or if that happens automagically?)

          Show
          jimklimov Jim Klimov added a comment - This investigation pointed me to the fact that our Jenkins did not have the plugin installed. Probably some colleague heeded the warning that it is deprecated and removed it. Installing it back "without restart" did not get the SCMs seen however; will try to Reload config from disk, or will restart Jenkins at night. I suppose some safety-belt is needed for these warnings and/or removals, to say that "there are (nontrivial?) configurations (global or in jobs) for a plugin, are you sure you want to remove it?"... I see a number of such alerts for warnings-analysis related plugins that are all superseded by one survivor, but I have no idea if people played with them and abandoned, or if some job actually uses them and has to be migrated (or if that happens automagically?)
          Hide
          jimklimov Jim Klimov added a comment -

          So, Reload from disk did not help; waiting for local evening to restart Jenkins. The on-disk config.xml files of those impacted jobs are not changed, scm tags still there.

          Show
          jimklimov Jim Klimov added a comment - So, Reload from disk did not help; waiting for local evening to restart Jenkins. The on-disk config.xml files of those impacted jobs are not changed, scm tags still there.
          Hide
          jimklimov Jim Klimov added a comment -

          Also found something I did not notice or realize before, that with Git SCM I can add several repositories. However it seems to just add several origins to the current workspace, probably for redundancy, so is not a replacement for Multi SCM even if that only combines several Git repos (instantiating each into its own checkout directory per additional behaviors, in particular). Did not work well when I tried to add our huge reference repo location

          Show
          jimklimov Jim Klimov added a comment - Also found something I did not notice or realize before, that with Git SCM I can add several repositories. However it seems to just add several origins to the current workspace, probably for redundancy, so is not a replacement for Multi SCM even if that only combines several Git repos (instantiating each into its own checkout directory per additional behaviors, in particular). Did not work well when I tried to add our huge reference repo location
          Hide
          markewaite Mark Waite added a comment -

          Yes, the git plugin has a novel concept that it can be given a list of multiple repositories. The contents of that list are assumed to be duplicates of the same repository, possibly in different locations or from different servers. I don't understand why that flexibility is allowed and I don't test very much to confirm its behavior. One of many oddities that are intentionally left in the git plugin to reduce accidental incompatibilities for users.

          Show
          markewaite Mark Waite added a comment - Yes, the git plugin has a novel concept that it can be given a list of multiple repositories. The contents of that list are assumed to be duplicates of the same repository, possibly in different locations or from different servers. I don't understand why that flexibility is allowed and I don't test very much to confirm its behavior. One of many oddities that are intentionally left in the git plugin to reduce accidental incompatibilities for users.
          markewaite Mark Waite made changes -
          Assignee Mark Waite [ markewaite ]
          Hide
          jimklimov Jim Klimov added a comment -

          In the end, after re-installing Multiple SCM Plugin and restarting Jenkins, situation got back to normal.

          Show
          jimklimov Jim Klimov added a comment - In the end, after re-installing Multiple SCM Plugin and restarting Jenkins, situation got back to normal.
          jimklimov Jim Klimov made changes -
          Resolution Not A Defect [ 7 ]
          Status Open [ 1 ] Closed [ 6 ]

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            jimklimov Jim Klimov
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: