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

Manual promotion : Bad build number and project name in ext-email

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • promoted-builds-plugin
    • None
    • Hudson 1.343, using email-ext plugin

      I suppose this is compatibility problem with the plugin email-ext.
      What occurs is the following :

      Mail title : 5 » promotion » Promo1 - Build # 5 - Building!
      Mail body : 5 » promotion » Promo1 5

      email-ext config title : $DEFAULT_SUBJECT
      emain-ext config body : $PROJECT_NAME $BUILD_NUMBER

      I tried to set a variable like you did with PROMOTED_URL using the following but I failed (Indeed, PROMOTED_URL is not resolved)

      In Promotion.java:67
      <code>
      @Override
      public EnvVars getEnvironment(TaskListener listener) throws IOException, InterruptedException

      { EnvVars e = super.getEnvironment(listener); String rootUrl = Hudson.getInstance().getRootUrl(); e.put("PROMOTED_NAME","nameTest"); e.put("PROMOTED_NUMBER",Integer.toString(targetBuildNumber)); if(rootUrl!=null) e.put("PROMOTED_URL",rootUrl+getTarget().getUrl()); return e; }

      </code>

          [JENKINS-5692] Manual promotion : Bad build number and project name in ext-email

          damickjj added a comment -

          I added this to prefix the promoted build's environment into the promotion tasks. Then in my emailext config i could use: ${ENV,var="PROMOTED_BUILD_URL"} etc...

          Hope this helps, I'd love to see this get added to the mainline..

          Index: src/main/java/hudson/plugins/promoted_builds/Promotion.java
          ===================================================================
          — src/main/java/hudson/plugins/promoted_builds/Promotion.java (revision 30880)
          +++ src/main/java/hudson/plugins/promoted_builds/Promotion.java (working copy)
          @@ -61,10 +61,14 @@
          public Status getStatus()

          { return getTarget().getAction(PromotedBuildAction.class).getPromotion(getParent().getName()); }

          -
          +
          @Override
          public EnvVars getEnvironment(TaskListener listener) throws IOException, InterruptedException {
          EnvVars e = super.getEnvironment(listener);
          + EnvVars parentEnv = this.getTarget().getEnvironment(listener);
          + for (String key : parentEnv.keySet())

          { // append promoted build's env + e.put("PROMOTED_" + key, parentEnv.get(key)); + }

          String rootUrl = Hudson.getInstance().getRootUrl();
          if(rootUrl!=null)
          e.put("PROMOTED_URL",rootUrl+getTarget().getUrl());

          damickjj added a comment - I added this to prefix the promoted build's environment into the promotion tasks. Then in my emailext config i could use: ${ENV,var="PROMOTED_BUILD_URL"} etc... Hope this helps, I'd love to see this get added to the mainline.. Index: src/main/java/hudson/plugins/promoted_builds/Promotion.java =================================================================== — src/main/java/hudson/plugins/promoted_builds/Promotion.java (revision 30880) +++ src/main/java/hudson/plugins/promoted_builds/Promotion.java (working copy) @@ -61,10 +61,14 @@ public Status getStatus() { return getTarget().getAction(PromotedBuildAction.class).getPromotion(getParent().getName()); } - + @Override public EnvVars getEnvironment(TaskListener listener) throws IOException, InterruptedException { EnvVars e = super.getEnvironment(listener); + EnvVars parentEnv = this.getTarget().getEnvironment(listener); + for (String key : parentEnv.keySet()) { // append promoted build's env + e.put("PROMOTED_" + key, parentEnv.get(key)); + } String rootUrl = Hudson.getInstance().getRootUrl(); if(rootUrl!=null) e.put("PROMOTED_URL",rootUrl+getTarget().getUrl());

          damickjj added a comment -

          patch file..

          damickjj added a comment - patch file..

          svd added a comment - - edited

          I would add my vote for applying patch proposed by damickjj.
          I use it in my environment. In addition to this patch, I also removed PROMOTED_URL variable from environment, as it will be exposed as PROMOTED_BUILD_URL variable. Though it breaks backward compatibility, so it is up to you to decide on this.
          My changes are available at https://github.com/svd/hudson-promoted-builds/commits/promotion-env

          svd added a comment - - edited I would add my vote for applying patch proposed by damickjj. I use it in my environment. In addition to this patch, I also removed PROMOTED_URL variable from environment, as it will be exposed as PROMOTED_BUILD_URL variable. Though it breaks backward compatibility, so it is up to you to decide on this. My changes are available at https://github.com/svd/hudson-promoted-builds/commits/promotion-env

          Peter Hayes added a comment -

          I didn't notice this issue until I committed similar changes into the plugin. I did something similar except that I focused only on passing through the promoted builds parameters, not the entire build environment. Here's my commit:

          https://github.com/jenkinsci/promoted-builds-plugin/commit/fa28c7807f88f9ec8ca9e691e24fa796ee90f6df

          Will that meet your needs or do you need the entire environment? I can't tell from this issue what variables you are trying to access.

          Peter Hayes added a comment - I didn't notice this issue until I committed similar changes into the plugin. I did something similar except that I focused only on passing through the promoted builds parameters, not the entire build environment. Here's my commit: https://github.com/jenkinsci/promoted-builds-plugin/commit/fa28c7807f88f9ec8ca9e691e24fa796ee90f6df Will that meet your needs or do you need the entire environment? I can't tell from this issue what variables you are trying to access.

          damickjj added a comment -

          Mainly using:
          JOB_NAME
          SVN_REVISION
          BUILD_NUMBER
          BUILD_ID
          BUILD_URL
          and other environment variables defined for that job.

          I want to make sure these are from the build, not the promotion job which is why i added the namespace "PROMOTED_" since the build url was link to the promotion, not the actual build. But it's been a while, maybe this works right now?

          damickjj added a comment - Mainly using: JOB_NAME SVN_REVISION BUILD_NUMBER BUILD_ID BUILD_URL and other environment variables defined for that job. I want to make sure these are from the build, not the promotion job which is why i added the namespace "PROMOTED_" since the build url was link to the promotion, not the actual build. But it's been a while, maybe this works right now?

          svd added a comment -

          Making build parameters available is another great idea! I like both.
          Like damickjj mentioned, various environment variables may be needed for some people, while others may need parameter values.

          svd added a comment - Making build parameters available is another great idea! I like both. Like damickjj mentioned, various environment variables may be needed for some people, while others may need parameter values.

          Peter Hayes added a comment -

          PROMOTED_URL has been there and then I also added PROMOTED_JOB_NAME and PROMOTED_NUMBER. I just added BUILD_ID. Is SVN_REVISION the revision of the build being promoted or is it the revision of the workspace at the time the build is promoted?

          Peter Hayes added a comment - PROMOTED_URL has been there and then I also added PROMOTED_JOB_NAME and PROMOTED_NUMBER. I just added BUILD_ID. Is SVN_REVISION the revision of the build being promoted or is it the revision of the workspace at the time the build is promoted?

          Peter Hayes added a comment -

          I'm also trying to figure out how the environment that is being generated by your patch is any different than the environment that is being seeded by the promotion itself. Can you do a comparison between the PROMOTED_ variables and the others? I expect JOB_NAME, BUILD_NUMBER, BUILD_ID, BUILD_URL to be different, but I'm not sure about any others.

          Peter Hayes added a comment - I'm also trying to figure out how the environment that is being generated by your patch is any different than the environment that is being seeded by the promotion itself. Can you do a comparison between the PROMOTED_ variables and the others? I expect JOB_NAME, BUILD_NUMBER, BUILD_ID, BUILD_URL to be different, but I'm not sure about any others.

          damickjj added a comment -

          i finally was able to come back around to this, here is more info:

          ${ENV,var="PROMOTED_NUMBER"} => 46
          ${ENV,var="PROMOTED_JOB_NAME"} => myproj
          ${ENV,var="BUILD_URL"} => http://build3.xxxx.com/job/myproj/46/promotion/myproj_to_QA/promotionBuild/10

          I'd really like to be able to get the SVN_REVISION of that used in the build that i'm promoting. The other issue is that I have some defined environment variables that are used for the build VERSION is my example, which I'd like to add to the email that is generated from the promotion.

          damickjj added a comment - i finally was able to come back around to this, here is more info: ${ENV,var="PROMOTED_NUMBER"} => 46 ${ENV,var="PROMOTED_JOB_NAME"} => myproj ${ENV,var="BUILD_URL"} => http://build3.xxxx.com/job/myproj/46/promotion/myproj_to_QA/promotionBuild/10 I'd really like to be able to get the SVN_REVISION of that used in the build that i'm promoting. The other issue is that I have some defined environment variables that are used for the build VERSION is my example, which I'd like to add to the email that is generated from the promotion.

            petehayes Peter Hayes
            tdutreui tdutreui
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: