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

The child/remote job is caused with incorrect parameters

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker

      After upgrade plugin Parameterized-Remote-Trigger from 3.1.5.1 to 3.1.6.1

      the child job is caused with incorrect parameter

       

      Everything works properly in Freestyle-type(with plugin version 3.1.6.1) job

      and the issue with Pipeline-type (with plugin version 3.1.6.1) job

       

      In my pipeline job I use the next parameters:

      parameters: """
      BRANCH_NAME_APP=${BRANCH_NAME_APP_CORE_SERVICE}
      BRANCH_NAME_INFRA=${BRANCH_NAME_INFRA}
      ENV_TYPE=${ENV_TYPE}
      DEPLOY_ENABLE=${DEPLOY_ENABLE}""", 

      Then after building with the parameters parent's job
      For, example

      BRANCH_NAME_APP=staging-dev-test
      BRANCH_NAME_INFRA=master
      ENV_TYPE=feature-3
      DEPLOY_ENABLE=true 
       

      In the console parent job I see call the child job(k8s-base-downstream-core-service-MONOLITH) with correct values:

      ##############################################################################
      Parameterized Remote Trigger Configuration:
      - job: k8s-base-downstream-core-service-MONOLITH 
      - remoteJenkinsName: Jenkins-MyCompany
      - parameters: { BRANCH_NAME_INFRA=master, BRANCH_NAME_APP=staging-dev-test, ENV_TYPE=feature-3, DEPLOY_ENABLE=true}
      - blockBuildUntilComplete: true
      - connectionRetryLimit: 5
      - trustAllCertificates: false
      ##############################################################################

      However, the child job is started with its default parameter values and ignores those parameters passed via the parent job

       

      Moreover, when I try to generate a Pipeline snippet in Pipeline Generator I get such error:

      no public field 'parameterFile' (or getter method) found in class org.jenkinsci.plugins 

      I have attached appropriate logs for pipeline generator

       

      When the plugin is downgraded to version 3.1.5.1 the issue is resolved (as the pipeline job as and pipeline generator work properly)

          [JENKINS-68773] The child/remote job is caused with incorrect parameters

          KaiHsiang Chang added a comment - - edited

          You can refer this for reference

          https://issues.jenkins.io/browse/JENKINS-68831

          KaiHsiang Chang added a comment - - edited You can refer this for reference https://issues.jenkins.io/browse/JENKINS-68831

          We stumbled upon the same issue here. The caller job does not report any issue or error, but the parameters are not passed to the called job.

          This is an incompatability which is not even reported on the Jenkins Plugin upgrade page nor in the plugin documentation. Moreover, this is clearly a blocker because you're forced to update all Jenkinsfiles of all projects and branches when upgrading the plugin. This is just not feasible for us, so we'd have to stick to version 3.1.5.1 forever.

          Please, consider to make this work in a compatible way!

          Christoph Amshoff added a comment - We stumbled upon the same issue here. The caller job does not report any issue or error, but the parameters are not passed to the called job. This is an incompatability which is not even reported on the Jenkins Plugin upgrade page nor in the plugin documentation. Moreover, this is clearly a blocker because you're forced to update all Jenkinsfiles of all projects and branches when upgrading the plugin. This is just not feasible for us, so we'd have to stick to version 3.1.5.1 forever. Please, consider to make this work in a compatible way!

          Rene Kempen added a comment - - edited

          Rene Kempen added a comment - - edited See also https://issues.jenkins.io/browse/JENKINS-68898  

          I will patch the pom.xml for the breaking changes in recent days. 

          You will still need to upgrade the jenkinsfiles, the release comprised a UI change which is a good improvement and unlikely to compatible with the old one. 

          You can choose to stay in 3.1.5.1,

          sorry for that forgetting to mark it as a breaking change, but the migration efforts will always exist. 

           

          Or if you want a compatible version for both UI and parameters, PR welcome. 

          KaiHsiang Chang added a comment - I will patch the pom.xml for the breaking changes in recent days.  You will still need to upgrade the jenkinsfiles, the release comprised a UI change which is a good improvement and unlikely to compatible with the old one.  You can choose to stay in 3.1.5.1, sorry for that forgetting to mark it as a breaking change, but the migration efforts will always exist.    Or if you want a compatible version for both UI and parameters, PR welcome. 

          Well, the Release Notes are not telling anything useful about what is the (breaking) change, just "Complete the PR f1eb49cf in 3.1.6"; so without reading and understanding the sources of that PR I don't see what this is about, which is hard when you're not a plugin developer.

          I guess we're not the only Jenkins user having hundreds of jobs in dozens of branches, which makes it impossible to find and fix usage of triggerRemoteJob steps everywhere. As far as I remember, we were never before forced to fix Jenkinsfiles as result of any plugin update, so other plugins seem to handle upgrades in a compatible way. Please reconsider if there is any way to still support old Jenkinsfile calls (I don't care about the UI).

          Moreover, staying on 3.1.5.1 is also not an option because Jenkins would continue to offer the plugin updates in the update manager (still not flagged with the red incompatability box) and risk is high this is again picked up by somebody doing regular updates. We're probably forced to fork the plugin.

          Christoph Amshoff added a comment - Well, the Release Notes are not telling anything useful about what is the (breaking) change, just "Complete the PR f1eb49cf in 3.1.6"; so without reading and understanding the sources of that PR I don't see what this is about, which is hard when you're not a plugin developer. I guess we're not the only Jenkins user having hundreds of jobs in dozens of branches, which makes it impossible to find and fix usage of triggerRemoteJob steps everywhere. As far as I remember, we were never before forced to fix Jenkinsfiles as result of any plugin update, so other plugins seem to handle upgrades in a compatible way. Please reconsider if there is any way to still support old Jenkinsfile calls (I don't care about the UI). Moreover, staying on 3.1.5.1 is also not an option because Jenkins would continue to offer the plugin updates in the update manager (still not flagged with the red incompatability box) and risk is high this is again picked up by somebody doing regular updates. We're probably forced to fork the plugin.

          More release notes on github for 3.1.6 for your reference.

           

          Plugin mainteners have the right to decide when or why to merge or release, so I don't think I have to response/release as quick as you leaved a comment.

          As I said, if you want something that satisfy your requirements instantly, PR welcome.

          Furthermoer, you don't care about UI, but someone else does, and, the most important, they contributed.  

          Forking is a good idea if you're suffering about this "issue".

           

          Again, sorry for not noting the breaking change, but the change is a must with or without the red box.

          KaiHsiang Chang added a comment - More release notes on github for 3.1.6 for your reference.   Plugin mainteners have the right to decide when or why to merge or release, so I don't think I have to response/release as quick as you leaved a comment. As I said, if you want something that satisfy your requirements instantly, PR welcome. Furthermoer, you don't care about UI, but someone else does, and, the most important, they contributed.   Forking is a good idea if you're suffering about this "issue".   Again, sorry for not noting the breaking change, but the change is a must with or without the red box.

            cashlalala KaiHsiang Chang
            kamaok Eugene Kamenev
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: