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

GitHub plugin to make parameters from webhook data

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      I'm trying to build the git hash / branch that just got pushed. GitHub passes the correct webhook, and https://JENKINSURLHERE/log/webhooks/?auto_refresh=true shows me the correct data, but the build notes "After filtering out what's already been built: []\nNothing seems worth building, so falling back to the previously built revision:" then lists the git hash of the previous build.

      Most of the time the new code is the most recent code, but not always. Consider the case where different branch names yield different build steps – e.g. git-flow deploys release/* branches to the test server and dev to the dev server. In this case, I want to push a new branch name on a previously built git hash, and have it build again with different results.

      Here's steps to reproduce the problem:

      1. Given a repository on GitHub or GitHub Enterprise with some history (2 or 3 commits is enough)
      2. Given a build that listens to GitHub (or GitHub Enterprise) via webhook
      3. Given that the build has run a few times already
      4. Create a new branch on an old commit (not a tip), for example "initial commit"
      5. Push the new branch
      6. Note that the github webhook log shows the specified git hash and branch
      7. Note that it builds the tip, not the specified commit

      Failure cause:
      GitHub plugin only gets the repository url and committer name from the webhook data (see https://github.com/jenkinsci/github-plugin/blob/master/src/main/java/com/cloudbees/jenkins/GitHubWebHook.java#L175), it does not get the other details.

      Proposed solution:
      GitHub plugin creates parameters of relevant webhook data that other plugins / parameterized builds could leverage such as GIT_HASH, GIT_BRANCH, etc, etc. Plugins such as http://www.sourceprojects.org/jenkins-and-the-git-branch-selection could leverage these as parameterized build sources, or parameterized builds could consume these variables directly.

      Alternate solution:
      GitHub plugin could skip over `getCandidateRevisions` call completely and trigger the build with the webhook's specified git hash / branch

        Attachments

          Activity

          Hide
          simonmweber Simon Weber added a comment -

          I'm running into a similar issue: I need access to the hook actor, but the plugin throws that information away.

          Specific parameters sound good - this is what https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin does - but we might also want to dump the entire hook to an environment variable. I could probably send a PR for this at some point.

          Show
          simonmweber Simon Weber added a comment - I'm running into a similar issue: I need access to the hook actor, but the plugin throws that information away. Specific parameters sound good - this is what https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin does - but we might also want to dump the entire hook to an environment variable. I could probably send a PR for this at some point.
          Hide
          integer Kanstantsin Shautsou added a comment - - edited

          This looks like a known issue with branch specifying https://github.com/jenkinsci/github-plugin/pull/44

          Show
          integer Kanstantsin Shautsou added a comment - - edited This looks like a known issue with branch specifying https://github.com/jenkinsci/github-plugin/pull/44
          Hide
          lucasocio Leandro Lucarella added a comment -

          Also bumping into this, I always thought that the PUSH trigger only (and unconditionally) built whatever the hook payload told jenkins to build, not that the hook just triggered a Git poll. (I just discovered is documented behaviour)

          Show
          lucasocio Leandro Lucarella added a comment - Also bumping into this, I always thought that the PUSH trigger only (and unconditionally) built whatever the hook payload told jenkins to build, not that the hook just triggered a Git poll. (I just discovered is documented behaviour)

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            robrich Rob Richardson
            Votes:
            8 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated: