Open mrocklin opened 5 years ago
I think it is a very good idea. I guess we need to ask devops for Travis-CI integration?
I wonder if maybe @raydouglass or someone can give us sufficient credentials to set this up ourselves. We'll want the ability to restart builds and generaly manage the web-based CI I think.
Travis CI grants restart privileges to anyone with write access on the repo. So we likely don’t need a separate workflow for that part (unless I’m missing something).
Oh great
On Thu, Oct 3, 2019 at 4:11 PM jakirkham notifications@github.com wrote:
Travis CI grants restart privileges to anyone with write access on the repo. So we likely don’t need a separate workflow for that part (unless I’m missing something).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/rapidsai/ucx-py/issues/197?email_source=notifications&email_token=AACKZTGFZEPKWMZXJYFMWITQMZNZ7A5CNFSM4I3HM4I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAJTRVQ#issuecomment-538130646, or mute the thread https://github.com/notifications/unsubscribe-auth/AACKZTEKXK3DJBITO5ZJS6DQMZNZ7ANCNFSM4I3HM4IQ .
This would both ensure that ucx-py works well in CPU-only situations, and provide some redundancy in testing.
gpuCI actually runs builds on CPU-only machines. The ci/cpu/build.sh
script executed on a small matrix of CPU-only options. While this is used to build conda packages in other RAPIDS projects, that's not a hard requirement. If there are unit tests (or anything really) that can run without a GPU, they can be run in that script and effect the build result plus reporting to PRs.
If it's ok, I think I would actually still prefer to use travis-ci for CPU builds. It's a pretty standard service that a lot of the community is familiar with. If there isn't a strong need for us to own CI here I would prefer to keep to standard community solutions. Is that ok?
Currently in #177 we're adding CI using NVIDIA/RAPIDS infrastructure. This is great because it provides access to GPUs.
However, we might add a public service like Travis-CI or Circle-CI as well. This would both ensure that ucx-py works well in CPU-only situations, and provide some redundancy in testing.
Additionally, my hope is that by adding a more low-tech testing infrastructure we'll ensure that ucx-py is applicable in consumer hardware situations.