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

Provide environment variables like Parameterized Trigger Plugin

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • multijob-plugin
    • None

      The Parameterized Trigger Plugin, which the MultiJob Plugin depends on, makes the following environment variables available to future build steps if "Block until the triggered projects finish their builds" is enabled:

      • LAST_TRIGGERED_JOB_NAME="Last project started"
      • TRIGGERED_BUILD_NUMBER_<project name>="Last build number triggered"
      • TRIGGERED_JOB_NAMES="Comma separated list of all triggered projects"
      • TRIGGERED_BUILD_NUMBERS_<project name>="Comma separated list of build numbers triggered"
      • TRIGGERED_BUILD_RESULT_<project name>="Last triggered build result of project"
      • TRIGGERED_BUILD_RESULT_<project name>RUN<build number>="Result of triggered build for build number"
      • TRIGGERED_BUILD_RUN_COUNT_project name>="Number of builds triggered for the project"

      It would be nice to have these for each phase (prefixed with the phase name)), too. Esp. TRIGGERED_BUILD_NUMBERS is important if artifacts need to copied from the triggered builds.

          [JENKINS-25675] Provide environment variables like Parameterized Trigger Plugin

          Regarding my use-case to copy artifacts from a phase-job, I just realized there's a separate issue for that [1] which is also already backed up by a PR [2].

          [1] https://issues.jenkins-ci.org/browse/JENKINS-25111
          [2] https://github.com/jenkinsci/tikal-multijob-plugin/pull/54

          Sebastian Schuberth added a comment - Regarding my use-case to copy artifacts from a phase-job, I just realized there's a separate issue for that [1] which is also already backed up by a PR [2] . [1] https://issues.jenkins-ci.org/browse/JENKINS-25111 [2] https://github.com/jenkinsci/tikal-multijob-plugin/pull/54

          Josh Davidson added a comment -

          I also am in need of this functionality. My situation is similar. I have a top level job that kicks off "product" builds for various platforms. Currently, I'm kicking these off via the parameterized trigger plugin and blocking. Once all of the product builds are complete, there are a series of cross-platform test/checkout jobs that run against the product. In order to ensure the jobs run against the exact product built by the top-level job, the build number is passed in via parameter.

          I attempted to convert the top-level job to a mutljob project this afternoon and ran into issues after discovering that there appears to be no way to gather the build numbers of jobs kicked off in a phase.

          Josh Davidson added a comment - I also am in need of this functionality. My situation is similar. I have a top level job that kicks off "product" builds for various platforms. Currently, I'm kicking these off via the parameterized trigger plugin and blocking. Once all of the product builds are complete, there are a series of cross-platform test/checkout jobs that run against the product. In order to ensure the jobs run against the exact product built by the top-level job, the build number is passed in via parameter. I attempted to convert the top-level job to a mutljob project this afternoon and ran into issues after discovering that there appears to be no way to gather the build numbers of jobs kicked off in a phase.

          Brantone added a comment -

          I just tried this and got a value for "LAST_TRIGGERED_JOB_NAME"

          Brantone added a comment - I just tried this and got a value for "LAST_TRIGGERED_JOB_NAME"

          Well, we'd need to have these variables per phase, so that the job containing the multijob build step can know which builds were triggered in the phase jobs in order to be able to copy artifacts form these builds.

          Sebastian Schuberth added a comment - Well, we'd need to have these variables per phase, so that the job containing the multijob build step can know which builds were triggered in the phase jobs in order to be able to copy artifacts form these builds.

          It looks like in latest releases they updated this so we get more ENV vars for the mutlijob phases and the builds it kicked off, but there is an issue if you have 1 phase that kicks off 45+ of the same job (using different params to pass to them).. what happens is you end up with build vars for most of those runs, but it always loses a few

          Lorelei McCollum added a comment - It looks like in latest releases they updated this so we get more ENV vars for the mutlijob phases and the builds it kicked off, but there is an issue if you have 1 phase that kicks off 45+ of the same job (using different params to pass to them).. what happens is you end up with build vars for most of those runs, but it always loses a few

          Version 1.17 indeed introduced a lot of useful variables, see https://github.com/jenkinsci/tikal-multijob-plugin/blob/master/AboutNewVariables.md.

          However, I still don't see any variable that provides the build numbers of the triggered jobs in a phase.

          Sebastian Schuberth added a comment - Version 1.17 indeed introduced a lot of useful variables, see https://github.com/jenkinsci/tikal-multijob-plugin/blob/master/AboutNewVariables.md . However, I still don't see any variable that provides the build numbers of the triggered jobs in a phase.

          Sebastian – I am seeing build vars like this for my triggered jobs in a phase
          GRTE_SELF_SERVICE___SEQUOIA_BVT_10_BUILD_NUMBER 16439
          GRTE_SELF_SERVICE___SEQUOIA_BVT_10_BUILD_RESULT SUCCESS
          GRTE_SELF_SERVICE___SEQUOIA_BVT_11_BUILD_NUMBER 16442
          GRTE_SELF_SERVICE___SEQUOIA_BVT_11_BUILD_RESULT SUCCESS
          GRTE_SELF_SERVICE___SEQUOIA_BVT_12_BUILD_NUMBER 16425

          The name of the jobs I am triggering is "GRTE Self Service Sequoia BVT"

          Lorelei McCollum added a comment - Sebastian – I am seeing build vars like this for my triggered jobs in a phase GRTE_SELF_SERVICE___SEQUOIA_BVT_10_BUILD_NUMBER 16439 GRTE_SELF_SERVICE___SEQUOIA_BVT_10_BUILD_RESULT SUCCESS GRTE_SELF_SERVICE___SEQUOIA_BVT_11_BUILD_NUMBER 16442 GRTE_SELF_SERVICE___SEQUOIA_BVT_11_BUILD_RESULT SUCCESS GRTE_SELF_SERVICE___SEQUOIA_BVT_12_BUILD_NUMBER 16425 The name of the jobs I am triggering is "GRTE Self Service Sequoia BVT"

          Thanks lorelei, I can confirm the variables to be present. However, I believe there is a bug in what the number preceeding "_BUILD" refers to. IMO it should be the running job number throughout all phases. However, what it seems to be is the running number of the finished job. That is, the number is not stable WRT the order in which parallel jobs finish. This is important for my use-case as I need to assemble artifacts from the different phase jobs in a certain order.

          Anyway, I will file that as a new bug since the topic of this particular issue was to provide the environment variables, which was done.

          Sebastian Schuberth added a comment - Thanks lorelei , I can confirm the variables to be present. However, I believe there is a bug in what the number preceeding "_BUILD" refers to. IMO it should be the running job number throughout all phases. However, what it seems to be is the running number of the finished job. That is, the number is not stable WRT the order in which parallel jobs finish. This is important for my use-case as I need to assemble artifacts from the different phase jobs in a certain order. Anyway, I will file that as a new bug since the topic of this particular issue was to provide the environment variables, which was done.

          Thinking about it, I can fix it for my use-case by passing the running phase job number as a parameter to the phase job, and let it write results to a file containing that number. Then I use the "<jobName>_<runCount>_BUILD_NUMBER" variables to copy artifacts from all triggered builds (not caring about the order), and then assembling the result files based on the running phase job number that's part of the result file names. So all is good

          Sebastian Schuberth added a comment - Thinking about it, I can fix it for my use-case by passing the running phase job number as a parameter to the phase job, and let it write results to a file containing that number. Then I use the "<jobName>_<runCount>_BUILD_NUMBER" variables to copy artifacts from all triggered builds (not caring about the order), and then assembling the result files based on the running phase job number that's part of the result file names. So all is good

            mcantin Mathieu Cantin
            sschuberth Sebastian Schuberth
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: