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

Expose new env var containing job name without build axis information appended

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • matrix-project-plugin
    • None

      On https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project, section entitled "Jenkins Set Environment Variables" there is a list of useful env vars which I can pick up in my build scripts.

      When you use a "multi-configuration project" the JOB_NAME, depending on your build axis names, gets resolved to something like:

      JOB_NAME=projectName/COMPILER=CL,CONFIG=Debug,PLATFORM=Win32

      Can you expose a new env var which just contains the project name without all the build axis information?

      In my setup I have "Copy files into the job's workspace before building" enabled and my "Files to copy" field contains:

      jobs/projectName/builds/${BUILD_ID}/changelog.xml

      Obviously I'd like to replace "projectName" with the new env var - this would help me maintain a growing number of projects.

          [JENKINS-9905] Expose new env var containing job name without build axis information appended

          Oleg Nenashev added a comment -

          danielbeck, my use-case is almost similar to Andrey's one.
          We use an automatic reporting flows, which add job names to test classpathes. Since the parsing of BUILD_ID and JOB_NAME is a 'worst practice' in any case (formats may change at some point), the variable could be useful.

          The main challenge is to select a proper variable name, because JOB_NAME has been already occupied.
          IMO, MATRIX_PROJECT_NAME is a best option

          Oleg Nenashev added a comment - danielbeck , my use-case is almost similar to Andrey's one. We use an automatic reporting flows, which add job names to test classpathes. Since the parsing of BUILD_ID and JOB_NAME is a 'worst practice' in any case (formats may change at some point), the variable could be useful. The main challenge is to select a proper variable name, because JOB_NAME has been already occupied. IMO, MATRIX_PROJECT_NAME is a best option

          Andrey Upadyshev added a comment - - edited

          Oleg, I propose something like JOB_SHORT_NAME or JOB_ID or JOB_UNIQUE_NAME or JOB_BASE_NAME. IMO having MATRIX in the var name is not good idea because this variable should be present in both matrix and normal projects. In normal project this variable should have the same value as JOB_NAME. With such approach scripts using this variable can be simply reused in both matrix and normal projects.

          Andrey Upadyshev added a comment - - edited Oleg, I propose something like JOB_SHORT_NAME or JOB_ID or JOB_UNIQUE_NAME or JOB_BASE_NAME. IMO having MATRIX in the var name is not good idea because this variable should be present in both matrix and normal projects. In normal project this variable should have the same value as JOB_NAME. With such approach scripts using this variable can be simply reused in both matrix and normal projects.

          Oleg Nenashev added a comment -

          @Andrey
          I got the idea. In such case the core should be patched instead on Matrix Project plugin.
          I'd prefer to add a variable to Matrix Project as well in order to make it available in old core versions. The variable will be avauilable for both parent job and matrix configurations

          Oleg Nenashev added a comment - @Andrey I got the idea. In such case the core should be patched instead on Matrix Project plugin. I'd prefer to add a variable to Matrix Project as well in order to make it available in old core versions. The variable will be avauilable for both parent job and matrix configurations

          @Oleg
          It's OK for me. If var will be available only in matrix projects it still helps a lot.

          Andrey Upadyshev added a comment - @Oleg It's OK for me. If var will be available only in matrix projects it still helps a lot.

          Daniel Beck added a comment -

          I don't think core should be changed to add a variable that's identical to JOB_NAME is most cases.

          And while Matrix project plugin could define an extension point that provides a new variable for all job types, it'd only result in problems for users using that one instead of JOB_NAME and then disabling the plugin because they don't use it.

          A matrix-specific variable seems to be the best option.

          Daniel Beck added a comment - I don't think core should be changed to add a variable that's identical to JOB_NAME is most cases. And while Matrix project plugin could define an extension point that provides a new variable for all job types, it'd only result in problems for users using that one instead of JOB_NAME and then disabling the plugin because they don't use it. A matrix-specific variable seems to be the best option.

          @Daniel
          I agree that having a all job types variable that will disappear if matrix plugin uninstalled is a bad idea. But having such variable in core is worth to have. Users give job a name and it's absolutely natural that they want to have this name available in any project type.

          Andrey Upadyshev added a comment - @Daniel I agree that having a all job types variable that will disappear if matrix plugin uninstalled is a bad idea. But having such variable in core is worth to have. Users give job a name and it's absolutely natural that they want to have this name available in any project type.

          Daniel Beck added a comment -

          That variable already exists and it is called JOB_NAME. Matrix should probably have left that alone and introduced a new one for the job name including axis configuration, but now it's too late for that. Adding a new variable for the matrix parent job is the way to go.

          Daniel Beck added a comment - That variable already exists and it is called JOB_NAME. Matrix should probably have left that alone and introduced a new one for the job name including axis configuration, but now it's too late for that. Adding a new variable for the matrix parent job is the way to go.

          Oleg Nenashev added a comment -

          So, we have an agreement at least for Matrix Project plugin

          Oleg Nenashev added a comment - So, we have an agreement at least for Matrix Project plugin

          I agree with Daniel. Just want to note that IMO matrix job functionality should be in the core from the beginning. But we have what we have.
          Then probably MATRIX_JOB_NAME is a good name for variable. Scripts can check and use it if present, otherwise use standard JOB_NAME.

          Andrey Upadyshev added a comment - I agree with Daniel. Just want to note that IMO matrix job functionality should be in the core from the beginning. But we have what we have. Then probably MATRIX_JOB_NAME is a good name for variable. Scripts can check and use it if present, otherwise use standard JOB_NAME.

          Oleg Nenashev added a comment -

          I have no memory of this place. Seem I have not delivered the fix 

          Oleg Nenashev added a comment - I have no memory of this place. Seem I have not delivered the fix 

            Unassigned Unassigned
            tfields Thomas Fields
            Votes:
            6 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: