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

" 'Jenkinsfile' not found" due to race condition w/ webhooks and the GH Contents API

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • None

      The Symptom:

      When using an enterprise GHE that is running slow (or I imagine, with a very fast jenkins instance, maybe even on production GH), a check for a Jenkinsfile in the branch events will say that one was not found, even though there is a Jenkinsfile in the PR's origin branch, and in the target branch. This seems to happen if you "slam" GH by creating a commit, branch, and PR all in one go (which people do with automated commits).

       

      What I think is the cause:

      As far as I can tell, GitHubSCMProbe is relying on the contents API to determine if a new branch or PR has a Jenkinsfile. When building merge PRs, it uses the merge refs with the contents API, but the merge refs aren't actually ready yet when GH sends out its webhooks. To prove this, I spun up a ruby sinatra app that listens for a PR webhook and immediately calls back to GH with the contents API. This reliably fails to find a ref (returns "No commit found for the ref"), unless you put a short sleep between when it receives the webhook, and when it calls out for content. You can find that here: https://github.com/SpencerMalone/test-repo if you want to play with it yourself.

       

      This is probably something that GH needs to fix, so I've sent them a support ticket, but just incase they are unable to, or in case it takes an exceedingly long time, I've opened this.

       

      I think in cases where we get a ref not found from the contents API while responding to branch events, there should be a short delay + retry.

            Unassigned Unassigned
            spencermalone Spencer Malone
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: