Yes I know but I think this is an issue.
I'll try to explain:
1°) First, this would be a strong added value. For now the only added value is a slight performance improvement, allowing to use webhooks instead of polling to detect scm changes.
I'm talking about changing it into a useful feature by allowing to create jobs that does not checkout the repository but are still triggered by the github webhook.
2°) For now the design of this feature is wrong. There is a trigger "Build when a change is pushed to GitHub". I'm expecting that the build is triggered when a change is pushed to github (not to the scm of my project). If you want to keep on the scm change, the trigger should be the default trigger (build on scm change) and then handle triggering of the scm change event through webhook, either by a hook into git scm management or by creating a new type of scm manager "Github"
3°) Without this feature, the "Github project" field seems to be useless, maybe only used for some links ? If you consider Github = SCM, why is there such a "Github project" field ? why don't you use the scm setting for all github related things ?
4°) This change does not need to be a breaking one. The rule can be: when receiving a webhook, looks into "Github project" AND in scm(s) urls. This way, old configurations would continue to work after the update
Yes this is what I mean