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

Upgrade from LTS 1.651.1 to 1.651.2 broke functionality of parameterized trigger plugin

      After upgrading from 1.651.1 to 1.651.2, when accessing administration page, I found a warning about configuration versions.
      I found messages related to parameterized trigger and also promoted builds plugins, stating config version was 1.653.
      The option to change configuration compatibility only showed the same version 1.653.
      After applying it, however, the messages disappeared (though they appeared again later, perhaps because of executions of other tasks or new executions of the same ones).

      I have a commons task which is triggered via parameterized trigger plugin and receives from this plugin a file.
      The plugin si configured with some properties and a parameter factory to send one file to a concrete location and name of the common task.

      Before upgrading, everything worked fine.
      After upgrading, the task was triggered (therefore, the plugin found the file to send), but the file was never copied into the common-task workspace.

      Reverting to previous version, fixed the problem.

          [JENKINS-34954] Upgrade from LTS 1.651.1 to 1.651.2 broke functionality of parameterized trigger plugin

          Juan Farré added a comment -

          Juan Farré added a comment - Might all this be related? https://issues.jenkins-ci.org/browse/JENKINS-34775

          Juan Farré added a comment -

          Ok, I think I finally know what's going on.
          After the upgrade, you can only pass parameters to another task if they are declared in the task.
          When you pass a file as parameter, the name of the parameter is the taget path of the file.
          So, unless you always pass the file with the same name and in the same path, there is no way to declare a single parameter.

          I suggest to add an option to the plugin to specify the name of the parameter which will hold file's path as value and avoid passing file path as parameter name.

          Thanks!

          Juan Farré added a comment - Ok, I think I finally know what's going on. After the upgrade, you can only pass parameters to another task if they are declared in the task. When you pass a file as parameter, the name of the parameter is the taget path of the file. So, unless you always pass the file with the same name and in the same path, there is no way to declare a single parameter. I suggest to add an option to the plugin to specify the name of the parameter which will hold file's path as value and avoid passing file path as parameter name. Thanks!

          James Murphy added a comment -

          Hi,

          I think I am hitting the same issue. I am using Jenkins for our Continuous Integration Pipeline and over the weekend the Jenkins Master upgraded itself from 1.651.1 to 1.651.2, and several of our jobs that are using the parameterized trigger plugin are now failing. While I can revert back to 1.651.1, I am wondering what the solution going forward should be? Right now I have a shell script that runs in JobA, it creates a bunch of variables (for example, location to some of the build artifacts stored on an external file server) and pipes them to a file that I later pass to JobB using "Parameters from properties file". This works extremely well for us because we don't necessarily need to create the parameters in JobB before hand, as long as JobA passes them in via the properties file.

          Since I see there appear to be several people hitting the same issue with the parameterized trigger pluggin after upgrade to 1.651.2 or greater, I am wondering if there will be some fix to revert back the requirement that the job that is being triggered must pre-define/declare the parameters before they can be passed in?

          Thanks!

          James Murphy added a comment - Hi, I think I am hitting the same issue. I am using Jenkins for our Continuous Integration Pipeline and over the weekend the Jenkins Master upgraded itself from 1.651.1 to 1.651.2, and several of our jobs that are using the parameterized trigger plugin are now failing. While I can revert back to 1.651.1, I am wondering what the solution going forward should be? Right now I have a shell script that runs in JobA, it creates a bunch of variables (for example, location to some of the build artifacts stored on an external file server) and pipes them to a file that I later pass to JobB using "Parameters from properties file". This works extremely well for us because we don't necessarily need to create the parameters in JobB before hand, as long as JobA passes them in via the properties file. Since I see there appear to be several people hitting the same issue with the parameterized trigger pluggin after upgrade to 1.651.2 or greater, I am wondering if there will be some fix to revert back the requirement that the job that is being triggered must pre-define/declare the parameters before they can be passed in? Thanks!

          Hai Nguyen added a comment -

          I got the same issue, but from the jenkins.err.log, there is an entry to add -Dhudson.model.ParametersAction.keepUndefinedParameters=true to the argument list, and it worked for me. All the parameters are passed to downstream jobs.

          Hai Nguyen added a comment - I got the same issue, but from the jenkins.err.log, there is an entry to add -Dhudson.model.ParametersAction.keepUndefinedParameters=true to the argument list, and it worked for me. All the parameters are passed to downstream jobs.

          Max Trunov added a comment -

          https://jenkins.io/blog/2016/05/11/security-update/
          It's not a bug, it's a feature ))

          Max Trunov added a comment - https://jenkins.io/blog/2016/05/11/security-update/ It's not a bug, it's a feature ))

          Bo3b Johnson added a comment -

          We were stung by this particular change as well. This is really not a good strategy to make upgrading the server break things like this.

          Our server is behind a firewall and not at risk, so this change does nothing but inconvenience us, and make it necessary for us to avoid all future updates. We can't afford to have broken builds because of simply updating Jenkins. And we would like to take advantage of updates for any bug fixes, reliability, or performance improvements.

          Remember, this is on the LTS branch, we are specifically looking for stability over new features. You put us in a hard spot.

          I would strongly encourage you to adopt a more clear security model, where this sort of change is only approved for external facing servers, or perhaps a relaxed model for known secure servers.

          Bo3b Johnson added a comment - We were stung by this particular change as well. This is really not a good strategy to make upgrading the server break things like this. Our server is behind a firewall and not at risk, so this change does nothing but inconvenience us, and make it necessary for us to avoid all future updates. We can't afford to have broken builds because of simply updating Jenkins. And we would like to take advantage of updates for any bug fixes, reliability, or performance improvements. Remember, this is on the LTS branch, we are specifically looking for stability over new features. You put us in a hard spot. I would strongly encourage you to adopt a more clear security model, where this sort of change is only approved for external facing servers, or perhaps a relaxed model for known secure servers.

            huybrechts huybrechts
            jafarre Juan Farré
            Votes:
            3 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: