• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Jenkins 2.319.3
      github-branch-source 2.11.4

      As already written in JENKINS-39838 there is currently no CHANGE_AUTHOR_EMAIL provided by the github-branch-source-Plugin.

      This is likely the case because the payload of a GitHub webhook contains only the GITHUB_AUTHOR/GITHUB_AUTHOR_DISPLAY_NAME.

      Backstory: We recently switched from Bitbucket to Github and also had to change the plugins in our Jenkins. However we require CHANGE_AUTHOR_EMAIL so that an E-Mail is sent to the corresponding user when the build fails. This is only required because there are currently other bugs that prevent the emailext Plugin from working correctly like e.g. JENKINS-24638. CHANGE_AUTHOR_EMAIL was a good workaround for this problem when we used bitbucket.

      I think resolving the E-Mail can be done by querying the GitHub-API:
      e.g. https://api.github.com/repos/<OWNER>/<REPO>/commits/<REF> or https://api.github.com/repos/<OWNER>/<REPO>/commits?author=<LOGIN>
      This returns the corresponding GitHub user and the E-Mail which was used for committing.

          [JENKINS-67998] GitHub: Provide CHANGE_AUTHOR_EMAIL

          https://api.github.com/repos/<OWNER>/<REPO>/commits/<REF>

          That would give you the author email and the committer email, right? The other CHANGE_ environment variables give information about the pull request, so I don't think it makes sense to have CHANGE_AUTHOR_EMAIL examine a commit instead. Besides, if the author email or committer email is sufficient for your purposes, then you can get those by running e.g. sh(returnStdout: true, script: 'git rev-list -1 --no-commit-header --pretty=format:%ce HEAD') in a pipeline script; no need to change the plugin.

          Kalle Niemitalo added a comment - https://api.github.com/repos/<OWNER>/<REPO>/commits/<REF> That would give you the author email and the committer email, right? The other CHANGE_ environment variables give information about the pull request, so I don't think it makes sense to have CHANGE_AUTHOR_EMAIL examine a commit instead. Besides, if the author email or committer email is sufficient for your purposes, then you can get those by running e.g. sh(returnStdout: true, script: 'git rev-list -1 --no-commit-header --pretty=format:%ce HEAD') in a pipeline script; no need to change the plugin.

          Alex B added a comment -

          > That would give you the author email and the committer email, right?

          The problem is that I can't call it from the pipeline because the repository is private and I can't access the GitHub app (as far as I know) which is used inside the plugin.

          > Besides, if the author email or committer email is sufficient for your purposes, then you can get those by running...

          No I also can't get it like this.
          The mails are sent from a custom agent (and with a library) which doesn't have the repo checked out.
          Why a custom agent? If the build fails we use a different agent which is reserved only for mail sending so that the mails are sent immediately.
          Why a library? To de-duplicate pipeline code

          I also notice that my above proposal is not completely correct. Someone could e.g. open a PR but the person didn't commit on the affected branch.
          In this case it's likely that you have to use something like https://api.github.com/repos/<OWNER>/<REPO>/commits?author=<LOGIN> to get the PR creator's mail.
          Added this to the description.

          Alex B added a comment - > That would give you the author email and the committer email, right? The problem is that I can't call it from the pipeline because the repository is private and I can't access the GitHub app (as far as I know) which is used inside the plugin. > Besides, if the author email or committer email is sufficient for your purposes, then you can get those by running... No I also can't get it like this. The mails are sent from a custom agent (and with a library) which doesn't have the repo checked out. Why a custom agent? If the build fails we use a different agent which is reserved only for mail sending so that the mails are sent immediately. Why a library? To de-duplicate pipeline code I also notice that my above proposal is not completely correct. Someone could e.g. open a PR but the person didn't commit on the affected branch. In this case it's likely that you have to use something like https://api.github.com/repos/<OWNER>/<REPO>/commits?author=<LOGIN> to get the PR creator's mail. Added this to the description.

          GitHub also provides GET /users/{username}, but this gets the public email address from the user's profile, so this is not suitable for your purposes if the user chose not to display an email address to the whole world, or if the user prefers a different email address for notifications about the specific repository.

          In this case it's likely that you have to use something like https://api.github.com/repos/<OWNER>/<REPO>/commits?author=<LOGIN> to get the PR creator's mail.

          That could find zero or multiple email addresses for the specified GitHub login. I feel the plugin should not use such an unreliable thing automatically for CHANGE_AUTHOR_EMAIL. Rather, the plugin could provide a pipeline step that calls the GitHub API and returns the email addresses as an array.

          I can't access the GitHub app (as far as I know) which is used inside the plugin.

          AFAIK, Jenkins runs global pipeline libraries without sandboxing and lets them access everything. So if the pipeline library can find the GitHubSCMSource instance, then it should be able to imitate GitHubSCMSource.retrieve(SCMHead head, TaskListener listener) to get an org.kohsuke.github.GitHub instance, and use that to query the GitHub API. I don't know how stable the API of GitHubSCMSource is, though.

          Kalle Niemitalo added a comment - GitHub also provides GET /users/{username} , but this gets the public email address from the user's profile, so this is not suitable for your purposes if the user chose not to display an email address to the whole world, or if the user prefers a different email address for notifications about the specific repository. In this case it's likely that you have to use something like https://api.github.com/repos/<OWNER>/<REPO>/commits?author=<LOGIN> to get the PR creator's mail. That could find zero or multiple email addresses for the specified GitHub login. I feel the plugin should not use such an unreliable thing automatically for CHANGE_AUTHOR_EMAIL. Rather, the plugin could provide a pipeline step that calls the GitHub API and returns the email addresses as an array. I can't access the GitHub app (as far as I know) which is used inside the plugin. AFAIK, Jenkins runs global pipeline libraries without sandboxing and lets them access everything. So if the pipeline library can find the GitHubSCMSource instance, then it should be able to imitate GitHubSCMSource.retrieve(SCMHead head, TaskListener listener) to get an org.kohsuke.github.GitHub instance, and use that to query the GitHub API. I don't know how stable the API of GitHubSCMSource is, though.

            Unassigned Unassigned
            ab_xdev Alex B
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: