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

Parsing ivy descriptors step fails on a slave when custom ivy settings file is used

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • ivy-plugin
    • None
    • Linux

      We have a global custom ivy settings file that is used by the Jenkins jobs, that are using Ivy build trigger to run. Due to the StackOverflowError we are trying to find a path to migrate all jobs from being free-style to ivy jobs.
      The ivy settings file includes another file specific to the java version basing on the env variable JAVA_VERSION (named like extended.settings-${ENV.JAVA_VERSION})
      On master node this resolves properly and parsing ivy descriptors step works properly. But the same exact build fails if running on a slave.
      I tried to inject all sorts of variables using envInject plugin but it gives me the error all the time:

      Error while reading the default Ivy2.1 settings: failed to load settings from file "our_global_ivy_settings_file".xml: io problem while parsing config file "extended.settings-${ENV.JAVA_VERSION}.xml"

      Note that the variable in the file name was not expanded properly.

        1. ivy.hpi
          1.50 MB
        2. ivy.hpi
          1.50 MB
        3. ivy.hpi
          1.73 MB
        4. ivy.hpi
          1.73 MB

          [JENKINS-15779] Parsing ivy descriptors step fails on a slave when custom ivy settings file is used

          eguess74 created issue -

          eguess74 added a comment -

          Hi everyone. I need this bug/feature so much that I'm willing to pay 100.00 bucks for it.
          This offer is registered at FreedomSponsors (http://www.freedomsponsors.org/core/issue/95/parsing-ivy-descriptors-step-fails-on-a-slave-when-custom-ivy-settings-file-is-used).
          Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too)
          I'll then check it out and will gladly pay up!

          If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors!

          eguess74 added a comment - Hi everyone. I need this bug/feature so much that I'm willing to pay 100.00 bucks for it. This offer is registered at FreedomSponsors ( http://www.freedomsponsors.org/core/issue/95/parsing-ivy-descriptors-step-fails-on-a-slave-when-custom-ivy-settings-file-is-used ). Once you solve it (according to the acceptance criteria described there), just create a FreedomSponsors account and mark it as resolved (oh, you'll need a Paypal account too) I'll then check it out and will gladly pay up! If anyone else would like to throw in a few bucks to elevate the priority on this issue, you should check out FreedomSponsors!

          eguess74 added a comment -

          The offer was increased to $150.00

          eguess74 added a comment - The offer was increased to $150.00

          Bill Yordle added a comment -

          Have you tried clicking advanced on the Ant Builder section of your Ivy Module Configuration and then adding your variable to Properties Text field using the syntax "ENV.JAVA_VERSION=<your value here>"?

          Bill Yordle added a comment - Have you tried clicking advanced on the Ant Builder section of your Ivy Module Configuration and then adding your variable to Properties Text field using the syntax "ENV.JAVA_VERSION=<your value here>"?

          eguess74 added a comment - - edited

          yes, i did - unfortunately it doesn't work. Plus it wouldn't be a good solution because in our build system the project's build.xml file is responsible for specifying the JAVA_VERSION that should be used (if not specified the system uses default one). So i would like to avoid the necessity of specifying project's JAVA_VERSION in more than one place.

          eguess74 added a comment - - edited yes, i did - unfortunately it doesn't work. Plus it wouldn't be a good solution because in our build system the project's build.xml file is responsible for specifying the JAVA_VERSION that should be used (if not specified the system uses default one). So i would like to avoid the necessity of specifying project's JAVA_VERSION in more than one place.

          Would you be willing to create a small testcase project which demonstrates the bug?

          Johno Crawford added a comment - Would you be willing to create a small testcase project which demonstrates the bug?

          eguess74 added a comment -

          @Johno

          Currently, unfortunately, I have no way to reproduce the bug, as all our stuff is in the closed network. I will try to come up with something, but it is not guaranteed. I.e. the bug is easily reproducible on our setup, but it is not easy to reproduce the set up.

          My wild guess is that the variables initialization or usage is working a bit differently when build executed on slave vs master.

          eguess74 added a comment - @Johno Currently, unfortunately, I have no way to reproduce the bug, as all our stuff is in the closed network. I will try to come up with something, but it is not guaranteed. I.e. the bug is easily reproducible on our setup, but it is not easy to reproduce the set up. My wild guess is that the variables initialization or usage is working a bit differently when build executed on slave vs master.

          eguess74 added a comment -

          May be there is a simple race condition or something like that? The fact is that the ivy settings file is specified in the job configuration. When the build starts on the master the variables contained in build.xml are already read by the time the ivy descriptors parsing step starts. On slave though it is not working that way, so the variables are not yet initialized, so the parsing step fails. Does it make any sense?

          eguess74 added a comment - May be there is a simple race condition or something like that? The fact is that the ivy settings file is specified in the job configuration. When the build starts on the master the variables contained in build.xml are already read by the time the ivy descriptors parsing step starts. On slave though it is not working that way, so the variables are not yet initialized, so the parsing step fails. Does it make any sense?

          eguess74 added a comment -

          the offer was increased to $200

          eguess74 added a comment - the offer was increased to $200

          Johno Crawford added a comment - - edited

          To get a better understanding of what is going on I have created a snapshot with verbose logging enabled ( https://issues.jenkins-ci.org/secure/attachment/23032/ivy.hpi ). Would you please try it out and look for log messages which differ from master and slave? Log messages starting with the following might be interesting..

          Configured Ivy using custom settings
          Configured Ivy using default 2.1 settings
          Error while reading the default Ivy 2.1 settings

          Johno Crawford added a comment - - edited To get a better understanding of what is going on I have created a snapshot with verbose logging enabled ( https://issues.jenkins-ci.org/secure/attachment/23032/ivy.hpi ). Would you please try it out and look for log messages which differ from master and slave? Log messages starting with the following might be interesting.. Configured Ivy using custom settings Configured Ivy using default 2.1 settings Error while reading the default Ivy 2.1 settings
          Johno Crawford made changes -
          Attachment New: ivy.hpi [ 23031 ]

            gbois Gregory Boissinot
            eguess74 eguess74
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: