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

Parameterized downstream project is missing upstream-set parameters when used by mutliple upstream projects

      Came here through the Build Pipeline plugin issue tracker link. Since the migration from google code, an annoying bug got lost, which I wanted to reinstate here.

      There's a problem when reusing a parameterized downstream project in several upstream projects (with manual run trigger). Only the first upstream project successfully invokes the downstream project retaining parameters set using the groovy script workaround. Other invocations leave the parameters empty in the downstream project.

      Case in point: 30 application projects, 4 environments to deploy to. With this bug we need to duplicate a deploy script per application (per environment). So instead of 4 deploy scripts, we now have 120 deploy scripts.

      This occurs all the way up to the latest version (1.3.3).

      Related issues:
      https://code.google.com/p/build-pipeline-plugin/issues/detail?id=54
      https://code.google.com/p/build-pipeline-plugin/issues/detail?id=53

          [JENKINS-18162] Parameterized downstream project is missing upstream-set parameters when used by mutliple upstream projects

          Have you tried using the 1.3.4-SNAPSHOT version? We are using it just to make Manual Parameterized builds available. Bugs on rerun, but otherwise works. Haven't tested on Parameterized downstream project though.

          But I would much like that a 1.3.4 version was commited with current code all the same.

          Ole Christian Langfjæran added a comment - Have you tried using the 1.3.4-SNAPSHOT version? We are using it just to make Manual Parameterized builds available. Bugs on rerun, but otherwise works. Haven't tested on Parameterized downstream project though. But I would much like that a 1.3.4 version was commited with current code all the same.

          Benny Bottema added a comment - - edited

          I have tried it, but considering I'm working on a production server with 30 projects (plus the 120 duplicates), I was hesitant to commit more time investigating, considering the Run button is bugged with the 1.3.4-SNAPSHOT. Don't know if it fixes it, but it's unusable just the same. This is a rather big issue for us.

          Benny Bottema added a comment - - edited I have tried it, but considering I'm working on a production server with 30 projects (plus the 120 duplicates), I was hesitant to commit more time investigating, considering the Run button is bugged with the 1.3.4-SNAPSHOT. Don't know if it fixes it, but it's unusable just the same. This is a rather big issue for us.

          1.3.4-SNAPSHOT is indeed bugged with the run button, the retry being the most importent one I think. https://issues.jenkins-ci.org/browse/JENKINS-11105.

          But passing parameters seems to work for me, unless i do a retry. Using 1.3.4-SNAPSHOT a new "Manual build other projects" is available. Can't remember the exact name as I'm on sickleave for a month from the project. But for the build that is manually triggered, the "triggering" project has to transfer the parameters to the build a second time.

          As an example if your manual build is a parameterized build with the parameter VERSION, you have to repeat it like so:
          VERSION=$VERSION

          Even if the first triggered build had the parameter with exact same name. At least, that's what I've experienced. Hope it helps, and hope a 1.3.4 version could be tagged and uploaded soon.

          Ole Christian Langfjæran added a comment - 1.3.4-SNAPSHOT is indeed bugged with the run button, the retry being the most importent one I think. https://issues.jenkins-ci.org/browse/JENKINS-11105 . But passing parameters seems to work for me, unless i do a retry. Using 1.3.4-SNAPSHOT a new "Manual build other projects" is available. Can't remember the exact name as I'm on sickleave for a month from the project. But for the build that is manually triggered, the "triggering" project has to transfer the parameters to the build a second time. As an example if your manual build is a parameterized build with the parameter VERSION, you have to repeat it like so: VERSION=$VERSION Even if the first triggered build had the parameter with exact same name. At least, that's what I've experienced. Hope it helps, and hope a 1.3.4 version could be tagged and uploaded soon.

          Benny Bottema added a comment -

          sooo... any chance we can solve this situation soon?

          Benny Bottema added a comment - sooo... any chance we can solve this situation soon?

          Benny Bottema added a comment - - edited

          In an older Jenkins version (1.486, with build-pipeline 1.3.3) I looked up the /api/json for two deploy builds of the downstream project and noticed that the parameters are the same despite being triggered by different upstream builds in two separate pipelines. I also noticed the build-pipeline plugin modified the <publishers/> tag of the downstream project during the first deploy build, but with the second the publisher tag is left unmodified.

          In effect, the downstream project deployed the same application twice.

          Benny Bottema added a comment - - edited In an older Jenkins version (1.486, with build-pipeline 1.3.3) I looked up the /api/json for two deploy builds of the downstream project and noticed that the parameters are the same despite being triggered by different upstream builds in two separate pipelines. I also noticed the build-pipeline plugin modified the <publishers/> tag of the downstream project during the first deploy build, but with the second the publisher tag is left unmodified. In effect, the downstream project deployed the same application twice.

          David Fuenmayor added a comment - - edited

          I completely agree this is a very annoying bug and it's still affecting version 1.3.5
          It is a pity that after almost 2 years this is not yet fixed and because of this we have to give up using this plugin :/

          David Fuenmayor added a comment - - edited I completely agree this is a very annoying bug and it's still affecting version 1.3.5 It is a pity that after almost 2 years this is not yet fixed and because of this we have to give up using this plugin :/

          The fix for version 1.4.1 is not working for me (Jenkins 1.509.3)
          After triggering the same downstream project from two different upstream projects, after a few times the upstream parameters eventually disappear. It is funny that it was actually after a few tries that it started failing all over again.

          Steps to reproduce:
          1. Create a downstream project D that uses some build parameters (for instance a shell step: echo ${MY_VAR})
          2. Create Projects A and B. As post-build action select "Build Other Projects (manual step)" and select for both: Project D. Add some predefined parameters: (e.g MY_VAR = VALUE)
          3. Create two Build Pipeline Views: One for Project A and one for Project B
          4. Trigger downstream project D from Project A using its corresponding BP View
          5. Trigger downstream project D from Project B using its corresponding BP View
          6. Repeat 4 and 5 until D breaks (parameters disappear)

          David Fuenmayor added a comment - The fix for version 1.4.1 is not working for me (Jenkins 1.509.3) After triggering the same downstream project from two different upstream projects, after a few times the upstream parameters eventually disappear. It is funny that it was actually after a few tries that it started failing all over again. Steps to reproduce: 1. Create a downstream project D that uses some build parameters (for instance a shell step: echo ${MY_VAR}) 2. Create Projects A and B. As post-build action select "Build Other Projects (manual step)" and select for both: Project D. Add some predefined parameters: (e.g MY_VAR = VALUE) 3. Create two Build Pipeline Views: One for Project A and one for Project B 4. Trigger downstream project D from Project A using its corresponding BP View 5. Trigger downstream project D from Project B using its corresponding BP View 6. Repeat 4 and 5 until D breaks (parameters disappear)

          This functionality works with the latest release, unless your projects are inside of folders (cloudbees folder plugin).

          Dylan Williams added a comment - This functionality works with the latest release, unless your projects are inside of folders (cloudbees folder plugin).

            tomakehurst Tom Akehurst
            plantface Benny Bottema
            Votes:
            3 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: