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

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

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • artifactory-plugin
    • None

      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.

          [JENKINS-18016] Artifactory plugin adds arguments when editing a job configuration while the job is building

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

          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.

          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

          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

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

              Created:
              Updated: