5 ms·

How can a CI-service not support ANY GIT source? All this garbage surrounding GIT is just baffling.

mdaniel 4y ago
I would guess it falls into the "what assumptions does the runner make?" followed closely by "there is no standard for what env-var contains: the current branch, the commit sha, the commit message, the current pipeline identifier, ..." and a bazillion other bits of contextual information Made worse by: ok, fine, you magically have `eval $(git set-env-from-commit HEAD)`, now how do you report those run results back to the upstream UI, since there is for sure no standard for that
jrockway 4y ago
I doubt there was a problem cloning GitLab-hosted repos on CircleCI before this announcement. But there are plenty of non-Git things that these hosts do; pull requests, status checks, etc. I am guessing that "support for ..." entails all of those extras.
LukeShu 4y ago
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.)
- lapser 4y ago
  FWIW the first two are solved by git without any service. Git can set up a post receive hook, which could do the triggering. SSH key auth is a thing as part of Git+SSH. Sure I couldn't set this with e.g. GitLab without them supporting GitLab, but if I'm self-hosting a git service, this seems like a fine solution.
aeyes 4y ago
Because the integration is entirely built on webhooks and each Git hosting provider has their own.
marc_omorain 4y ago
You would be surprised at how little of the code in a CI product, like CircleCI, deals with git. On the other hand, there is a lot of code required to integrate with the VCS - authn, authz, webhooks, commit-status, etc.

I would guess it falls into the "what assumptions does the runner make?" followed closely by "there is no standard for what env-var contains: the current branch, the commit sha, the commit message, the current pipeline identifier, ..." and a bazillion other bits of contextual information Made worse by: ok, fine, you magically have `eval $(git set-env-from-commit HEAD)`, now how do you report those run results back to the upstream UI, since there is for sure no standard for that

jrockway 4y ago

I doubt there was a problem cloning GitLab-hosted repos on CircleCI before this announcement. But there are plenty of non-Git things that these hosts do; pull requests, status checks, etc. I am guessing that "support for ..." entails all of those extras.

LukeShu 4y ago

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.)

lapser 4y ago
FWIW the first two are solved by git without any service. Git can set up a post receive hook, which could do the triggering. SSH key auth is a thing as part of Git+SSH. Sure I couldn't set this with e.g. GitLab without them supporting GitLab, but if I'm self-hosting a git service, this seems like a fine solution.

aeyes 4y ago

Because the integration is entirely built on webhooks and each Git hosting provider has their own.

marc_omorain 4y ago

You would be surprised at how little of the code in a CI product, like CircleCI, deals with git. On the other hand, there is a lot of code required to integrate with the VCS - authn, authz, webhooks, commit-status, etc.