Jeremy Stanley <[email protected]> writes: > On 2017-05-25 00:33:10 +0000 (+0000), Tristan Cacqueray wrote: >> On May 24, 2017 11:04 pm, James E. Blair wrote: >> [...] >> >How does that sound? >> >> Thinking about further connections support, could this also works >> for a (theorical) mail based patch cross dependency?
Zuul's driver API has 3 separate, but relevant, concepts: Source: the canonical git repo for a project along with a place to fetch any proposed changes and metadata. Trigger: something that tells Zuul to enqueue a change. Reporter: some place that Zuul reports results. In v3, the three are completely separate. Theoretically we could write a driver which implemented the source interface against LKML. It would need a git repo (so I assume we would point it at one of the ones at kernel.org). Fetching the patch and git-am'ing it should be straightforward. Implementing the methods that determine whether a change is still "open" or whether it has "merged" might be a little less straightforward in this case (especially since the patch doesn't have a git sha that we can search for in the tree). The source driver would assume a 1:1 relationship with the changes (ie lkml.org/diff/...) and a single git repo. That strays a bit from how kernel development is done, in that there are a lot of git repos on kernel.org, and the changes may be designated for any of them (in the example above, "Please apply this to the samsung tree"). So we're not going to completely match the Linux kernel workflow without some further changes. But we're surprisingly close to being able to do something. > I can imagine wanting something like: > > Depends-On: https://lkml.org/lkml/diff/2017/5/24/668/1 > > ...where zuul will git am what it finds there. > >> What's the logic to match the Depends-On syntax to a connection >> driver? I expect it will be that we ask every driver in turn whether it handles this url, and the driver examines the hostname to see if it matches what it is configured for. If so, the Zuul will ask the driver for the change. > This brings up an additional question: how far can we stretch the > concept of a connection driver, and does it always need to be > something we can report back on in some way? Maybe we want to test a > Gerrit change or GutHub PR which requires a patch from the LKML (as > above) when rebuilding the kernel for a guest, but we don't ever > expect to report back to the LKML about anything. Would having a > generic HTTP(S) driver for things like this make sense? Because triggers and reporters are separate from sources, we can definitely configure them separately, and configure the system not to report back to LKML. Because we need a git repo to back changes (ie, to what do we apply that diff?), a generic HTTP(S) driver won't be sufficient. But the rest of what you suggest is fairly close to possible with the caveats above. Perhaps we should consider (in the future, after we get this thing out the door) extending the Depends-On syntax like: Depends-On: https://lkml.org/lkml/diff/2017/5/24/668/1 applied to https://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git/ In another post, Sean suggests allowing arbitrary text after the identifier. This is probably compatible with that, inasmuch as we can start by allowing arbitrary text, and then reclaim "applied to" as a keyword phrase later. -Jim _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
