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

Artifactory plugin adds arguments when editing a job configuration while the job is building

    Details

    • Similar Issues:

      Description

      We use the artifactory plugin and have ant ANT build step defined with a target of [build.all]

      When the job is building and we want to change the configuration, the build step will be reflected with targets of [build.all -lib "E:/Jenkins/workspace/artifactory-plugin/2.0.5" -listener org.jfrog.build.extractor.listener.ArtifactoryBuildListener ]

      It seems that this information is dynamically entered during build time, however if we click save on a job configuration this information will be persisted. If this happens multiple times, then the job target will contains duplicate copies of this information.

        Attachments

          Activity

          Hide
          walterk82 Walter Kacynski added a comment -

          I think this could be fixed by using a Build Listener like what the EnvInject plugin does. This would avoid changing the config.xml.

          Show
          walterk82 Walter Kacynski added a comment - I think this could be fixed by using a Build Listener like what the EnvInject plugin does. This would avoid changing the config.xml.
          Hide
          brianpcarr Brian Carr added a comment -

          In our normal (and sadly complex) build jobs we invoke ant twice. First ant complies and builds the database tools, then the database tools are used to build the test database, then ant is used to run all the tests. The configuration options are added to the second / last ant invocation while they are required in the build step (first invocation).

          There is an additional problem in that the library location is slave specific while the job can run on multiple slaves (above the e:/Jenkins/workspace requires that all slaves be run from e:/Jenkins/ which is not the case for our slaves).

          Our workaround is to use %WORKSPACE% relative references on the first invocation.

          I would recommend that all ant invocations get relative references, e.g. %WORKSPACE%/../../caches/artifactory-plugin/2.2.7

          Show
          brianpcarr Brian Carr added a comment - In our normal (and sadly complex) build jobs we invoke ant twice. First ant complies and builds the database tools, then the database tools are used to build the test database, then ant is used to run all the tests. The configuration options are added to the second / last ant invocation while they are required in the build step (first invocation). There is an additional problem in that the library location is slave specific while the job can run on multiple slaves (above the e:/Jenkins/workspace requires that all slaves be run from e:/Jenkins/ which is not the case for our slaves). Our workaround is to use %WORKSPACE% relative references on the first invocation. I would recommend that all ant invocations get relative references, e.g. %WORKSPACE%/../../caches/artifactory-plugin/2.2.7

            People

            • Assignee:
              eyalbe Eyal Ben Moshe
              Reporter:
              walterk82 Walter Kacynski
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: