As much as I want to agree with you, I get it: - To avoid polling, you want to be able to register a webhook to be notified when pushes happen. You're going t

As much as I want to agree with you, I get it: - To avoid polling, you want to be able to register a webhook to be notified when pushes happen. You're going to need Git-servicet-specific parsing of the webhook payload, and you probably want to be able to speak a Git-host-specific API to automatically register that webhook to make it easy for users. (Falling back to polling would be good, but few do.) - If you're a paid product, you definitely need to support private repos. You probably want to be able to speak a Git-service-specific API to set up the credentials to be able to do that `clone`; in GitHub parlance use the API to create a "deploy key", rather than requiring users to manually mint an SSH key, set up a bot account on the Git-service, add the SSH key to that account, and upload the SSH key to the CI-service. (Falling back to being able to provide a raw Git URL and credentials would be good, but few do.) - To avoid confusing user-account permission mismatches, you probably want to piggy-back on the Git-service's user system; supporting "sign-on with X" and using the Git-service's "is admin of this Git repo" for allowing access to your the CI-service's admin interface for that repo. - You want to be able to post statuses back to the Git-host. This takes a Git-service-specific API. (Falling back to letting the user provide their own script for posting statuses would be good, but few do.)