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

No e-mail sent after failed build triggered from another build

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I have following setup:

      1. 2 jobs:
        1. main job is configured to listed for SVN commit hook and build when commit happens
        2. deploy job is triggered by this plugin in non-blocking mode and does only a deployment (don't listen for SVN stuff)
      2. Email-ext setup on both jobs to e-mail in case of failure

      In case if failure of main job I get the e-mail, because actual e-mail address is retrieved from user, who did SVN commit, which triggered the build.

      However even though I've set "Include/passthrough Upstream SVN Revisons" I don't get e-mail. I guess this option doesn't pass the e-mail addresses from upstream job to be used in case of failure by Email-ext plugin.

        Attachments

          Activity

          Hide
          aik099 Alexander Obuhovich added a comment - - edited

          Even though I've set to passthrough SVN related info (included revisions) to the downstream job but it didn't work.

          Maybe problem is, with my setup. I have:

          1. upstream job that does 2 SVN checkouts and is triggered by SVN post-commit hook
          2. downstream job that deploys changes on staging server
          3. downstream job doesn't have any SVN related options set up

          See attached "SvnRevision_Dont_GetPasse..." image.

          Show
          aik099 Alexander Obuhovich added a comment - - edited Even though I've set to passthrough SVN related info (included revisions) to the downstream job but it didn't work. Maybe problem is, with my setup. I have: upstream job that does 2 SVN checkouts and is triggered by SVN post-commit hook downstream job that deploys changes on staging server downstream job doesn't have any SVN related options set up See attached "SvnRevision_Dont_GetPasse..." image.
          Hide
          aik099 Alexander Obuhovich added a comment - - edited

          Fingerprint Plugin helps you!: https://wiki.jenkins-ci.org/display/JENKINS/Fingerprint+Plugin It provides "Fingerprint files" in "Build" step.

          I've tried it, but it seems that fact, that I have several upstream jobs that trigger a same downstream deployment job and that all are using same "revision.txt" makes it hard for Jenkins to manage.

          Maybe I should create "projecta_revsision.txt", "projectb_revision.txt" in upstream job and pass that filename as a build parameter to downstream job. Then in fingerprint screen I won't see messages like "revision.txt" was introduced by "projecta" and last used by "projectb".

          Show
          aik099 Alexander Obuhovich added a comment - - edited Fingerprint Plugin helps you!: https://wiki.jenkins-ci.org/display/JENKINS/Fingerprint+Plugin It provides "Fingerprint files" in "Build" step. I've tried it, but it seems that fact, that I have several upstream jobs that trigger a same downstream deployment job and that all are using same "revision.txt" makes it hard for Jenkins to manage. Maybe I should create "projecta_revsision.txt", "projectb_revision.txt" in upstream job and pass that filename as a build parameter to downstream job. Then in fingerprint screen I won't see messages like "revision.txt" was introduced by "projecta" and last used by "projectb".
          Hide
          ikedam ikedam added a comment -

          I think fingerprints use not the name of files, but the content of files.
          You should output SVN_URL_1 additional to SVN_REVISION_1.

          I'm not sure how "Include/passthrough Upstream SVN Revisons" work.
          It may requires checkout also in downstream to have variables defined.
          "Predefined Parameters" always work and may be reliable.

          Show
          ikedam ikedam added a comment - I think fingerprints use not the name of files, but the content of files. You should output SVN_URL_1 additional to SVN_REVISION_1. I'm not sure how "Include/passthrough Upstream SVN Revisons" work. It may requires checkout also in downstream to have variables defined. "Predefined Parameters" always work and may be reliable.
          Hide
          aik099 Alexander Obuhovich added a comment -

          I'm not sure how "Include/passthrough Upstream SVN Revisons" work.

          Aren't the "parameterized-trigger" plugin developer?

          It may requires checkout also in downstream to have variables defined.

          That is my guess too.

          Show
          aik099 Alexander Obuhovich added a comment - I'm not sure how "Include/passthrough Upstream SVN Revisons" work. Aren't the "parameterized-trigger" plugin developer? It may requires checkout also in downstream to have variables defined. That is my guess too.
          Hide
          ikedam ikedam added a comment -

          parameterized-trigger-plugin just passes information to ensure subversion-plugin checkouts the same revision as upstream.
          Detailed behaviors, for example when variables are defined, are controlled by subversion-plugin.

          Show
          ikedam ikedam added a comment - parameterized-trigger-plugin just passes information to ensure subversion-plugin checkouts the same revision as upstream. Detailed behaviors, for example when variables are defined, are controlled by subversion-plugin.

            People

            • Assignee:
              huybrechts huybrechts
              Reporter:
              aik099 Alexander Obuhovich
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: