search

patch-graph / pass-the-fork

[WIP] inject forked dependencies into CI builds
MIT License
1 stars 1 forks source link

Cross CI triggers based on what files were modified #12

Open jayvdb opened 5 years ago

jayvdb commented 5 years ago

Being able to trigger a different CI engine for the same PR has some benefits that could attract a lot of interest.

The one that caused me to create a separate issue is that Travis doesnt have a way to finish successfully early.

https://travis-ci.community/t/how-to-skip-jobs-based-on-the-files-changed-in-a-subdirectory/2979/7

This could be done by having the "check what CI is needed" job done in one CI engine, which then triggers other CI to do longer running stages.

Another gap in CI at the moment is BSD support.

There is a CI service providing FreeBSD, and it would be nice to be able to easily trigger its API only when a change is likely to break on FreeBSD , in order to avoid using all of the free credits on silly builds where FreeBSD isnt worth spinning up.

https://travis-ci.community/t/freebsd-vms-support/2125/

To be honest also OSX support as Travis CI OSX works are painful to use, especially slow to start.

Bitrise CI is another CI work supporting, as it gives limited free credits, but has many OS which are not available by other CI providers.

I would love to be able to include proxy OSX and FreeBSD CI builds in the CI @ https://gitlab.com/coala/package_manager/pipelines

cben commented 4 years ago

Currently this project only has code to trigger Travis CI. I'm now using a special API that allows starting a build that's not coupled to a branch/PR: https://docs.travis-ci.com/user/triggering-builds/

It seems most other CIs don't have such APIs though. For example Cirrus explicitly says https://cirrus-ci.org/guide/build-life/:

Any build starts with a change pushed to GitHub.

OTOH https://github.com/cirruslabs/cirrus-ci-web/blob/master/schema.graphql#L253 does mention a createBuild() and per https://github.com/cirruslabs/cirrus-ci-docs/issues/465 it even sounds like it supports config overrides?

Anyway, we could in principle support any other CI system with a different implementation strategy: create a commit with the necessary dependency overrides, and push that to a branch.

I don't plan working on any non-travis CI in observable future; there is lots of basic stuff — mostly documenting how to use this at all — that I'd like to do first. But if you want to tackle it, PRs welcome, and I can provide advice.