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

copyartifact 1.26 does not expand label expressions in parameter field, copies all of them

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • copyartifact-plugin
    • None
    • linux jenkins 1.508

        [JENKINS-17365] copyartifact 1.26 does not expand label expressions in parameter field, copies all of them

        Julian Taylor added a comment -

        since version 1.26 copyartifact does not expand variables in the parameter filter.

        Previously I had such a setup:

        job-name/os=$os,arch=$arch

        where os and arch are either label expressions or environment variables of the nodes themselves (for non matrix jobs).
        So each job copied the one correct artifact from the other matrix jobs.

        with the latest update now the plugin does not properly handle this. The Parameter filter was created automatically like this:
        os=$os,arch=$arch

        but this has the effect that all artifacts of the parent matrix job are copied.
        They also land in variable qualified subfolders instead of the top level so it breaks all of my jobs.

        Julian Taylor added a comment - since version 1.26 copyartifact does not expand variables in the parameter filter. Previously I had such a setup: job-name/os=$os,arch=$arch where os and arch are either label expressions or environment variables of the nodes themselves (for non matrix jobs). So each job copied the one correct artifact from the other matrix jobs. with the latest update now the plugin does not properly handle this. The Parameter filter was created automatically like this: os=$os,arch=$arch but this has the effect that all artifacts of the parent matrix job are copied. They also land in variable qualified subfolders instead of the top level so it breaks all of my jobs.

        @Julian try putting the "job-name/os=$os,arch=$arch" bit in the field labeled "Project name".

        Seth Chisamore added a comment - @Julian try putting the "job-name/os=$os,arch=$arch" bit in the field labeled "Project name".

        Julian Taylor added a comment -

        that still works, but why does the plugin "fix" my jobs to the broken variant on their first build?
        can I disable that somehow?

        Julian Taylor added a comment - that still works, but why does the plugin "fix" my jobs to the broken variant on their first build? can I disable that somehow?

        Jesse Glick added a comment -

        The previous storage format was ambiguous about what was a parameter filter and what was part of the job path for e.g. matrix jobs. As of 1.26 an unambiguous format is used.

        There is a one-time migration which attempts to guess what you meant in the old case: if there is a / in the name, and there is a = in the name, and no job with the specified full name exists, then the name is split on the last /, with the first part being the project name and the second part being the parameter filter. Otherwise the name is assumed to be a matrix project name and the parameters field is left empty.

        I am not surprised that this heuristic is not correct in every case but I am not sure if it can be improved. If you think it can, please file a pull request against this plugin with a test demonstrating the more precise migration using @LocalData.

        Jesse Glick added a comment - The previous storage format was ambiguous about what was a parameter filter and what was part of the job path for e.g. matrix jobs. As of 1.26 an unambiguous format is used. There is a one-time migration which attempts to guess what you meant in the old case: if there is a / in the name, and there is a = in the name, and no job with the specified full name exists, then the name is split on the last / , with the first part being the project name and the second part being the parameter filter. Otherwise the name is assumed to be a matrix project name and the parameters field is left empty. I am not surprised that this heuristic is not correct in every case but I am not sure if it can be improved. If you think it can, please file a pull request against this plugin with a test demonstrating the more precise migration using @LocalData .

        Julian Taylor added a comment -

        for the record I avoided the autorewrite by changing <projectName> to <project> in all job xml files.

        Julian Taylor added a comment - for the record I avoided the autorewrite by changing <projectName> to <project> in all job xml files.

          Unassigned Unassigned
          jtaylor Julian Taylor
          Votes:
          0 Vote for this issue
          Watchers:
          3 Start watching this issue

            Created:
            Updated:
            Resolved: