-
Improvement
-
Resolution: Not A Defect
-
Major
-
None
-
any
The Github plugin has generally been very buggy for me, even on the latest version. The way I use it (which I think is very common, it's the way Travis and other hosted CI tools work by default) is with feature branches, to have Jenkins build every push to every branch on Github when it gets a webhook. The big issues I have are:
1. Every few days, it starts missing builds with no indication of what's going on. I see in the logs it gets the webhook pings from Github, but then it doesn't think there's anything to build. It sometimes fixes itself in an hour or two, or if I trigger a build manually that also fixes it.
2. There also seems to be a race condition where pushing branch A to github then pushing branch B shortly after can trigger a second build on branch A. In some cases, this seems to happen minutes after branch A has already completed, so I'm not sure it's actually a race condition. I haven't been able to reproduce this reliably or get much extra information.
3. When you first turn this on for a project, it builds all branches that exist on Github, many of which might be be on hold where there's really no need to build them right now at the expense of everything else. This swamps jenkins until they all complete.
4. Lastly, it doesn't work with the "rebuild" button plugin because the build is not parameterized, so rebuilding will rebuild whatever sha happened to run last, instead of rebuilding the sha of the run that you clicked "rebuild" on.
These issues could presumably all be fixed with enough effort (except maybe the last one), but it seems like this is generally a pretty bad strategy for running builds. Why does Jenkins need to do the error-prone work of fetching all branches, then diffing to see what it thinks has already built, with the side effect of a build being non-reproducible?
Why can't Jenkins run a parameterized build using the branch name & sha that are specified in the webhook? Github signs webhooks with HMAC based on a shared secret, so the secret could be set in the Jenkins config and the signature could be verified to prevent unauthorized builds.