I suspect it is something to with a custom patched plugin being upgraded to the supported one but not correctly updating the existing job configs.
Certainly it does result in a small amount of changes to the XML around config associated with the plugin. Why this is not happening when I ran it through the script console I have no idea, but saving via the UI seems to fix the problem. On 15 October 2014 23:03, jieryn <[email protected]> wrote: > I don't have the same findings as you. I @daily have an > infra_save_items job with an Execute system Groovy script of: > > for (item in hudson.model.Hudson.instance.items) { > println("Saving " + item); > item.save(); > } > > Not only does this work, but it does it quite quick; it also preserves > any sort of ACL permission system is in place. I find it helpful to > run this after a plugin update, I see the new versions of the plugins > in the jobs/*/config.xml. I'm using Jenkins LTS 1.565.3. > > > > On Wed, Oct 15, 2014 at 5:56 PM, Darragh Bailey <[email protected]> > wrote: > > > > Just went through an upgrade from an old version of jenkins/plugins and > > discovered that some jobs have not had their XML properly updated. > > > > This is resulting in odd behaviour where triggered jobs do not appear in > the > > UI and are not readable, but the associated files appear on-disk. > > > > By going to the configure page for some jobs have been able to confirm > that > > simply saving the job appears to sort the problem out. I suspect that > this > > forces the correct configuration options to be set. > > > > > > I've tried using the script console to iteratively call 'job.save()' and > > that doesn't appear to have the same effect, I'm guessing it requires > > putting the current configuration through the latest forms and saving the > > result to get a working config. Where as just calling save writes the > > current stored config to disk without it going through any of the form > > validation code in the plugins. > > > > > > Is it possible to mass trigger a save for each job defined? Have close to > > 2000, so doing this manually to catch the few broken ones is a bit of a > > chore. I've tried mechanize with the following in python: > > > > ####### > > import mechanize > > import base64 > > > > br = mechanize.Browser() > > username = "<insert>" > > apitoken = "<insert>" > > auth = 'Basic ' + base64.encodestring('%s:%s' % (username, > apitoken))[:-1] > > auth_header = ('Authorization', auth) > > br.addheaders = [auth_header] > > br.set_handle_robots(False) > > br.set_proxies({}) > > > > br.open("http://myjenkins/job/myjobname/configure";) > > > > br.select_form(name="config") > > br.submit(name="Submit") > > > > ####### > > > > And all I see in response is "mechanize._response.httperror_seek_wrapper: > > HTTP Error 400: This page expects a form submission". So it's not a > simple > > straight forward submission. > > > > Any other way to essentially force the job configs to be updated based on > > the latest plugin options via the UI? > > > > -- > > Darragh > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Jenkins Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-users/qcjgD8pR0hY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Darragh Bailey "Nothing is foolproof to a sufficiently talented fool" -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
