make travis opt-in?

[beckermr]

We're having a lot of trouble with a token rotation right now (conda-forge/status#137) due to travis API rate limits. Some of this was a poorly coded bot on my part for sure. However, with cross-compilation working reasonably well these days, it could be argued that travis should be opt-in. We have other opt-in CI services coming up as well. So maybe now is the time to make this change and develop the infrastructure we'd need for it.

[beckermr]

cc @conda-forge/core

[beckermr]

cc @h-vetinari for viz

[beckermr]

This could support the GPU ci opt-in as well. @jaimergp

[jaimergp]

Yes, I have been thinking about this for Cirun.

We need a core-controlled list somewhere. It doesn't need to traverse the graph, so it can be controlled by admin-requests. For Cirun we have conda-forge/.cirun, maybe we can have conda-forge/.travis too? Or maybe we keep things in different repos.

[h-vetinari]

cc @h-vetinari for viz

Thanks for the ping. We've gone back and forth on the default for aarch/ppc as I recall. For feedstocks that can run on azure (either in emulation or better cross-compilation), I tend to do that, because Travis is just too flaky for my taste, on top of very long queues.

So I know how to work around it in either case, but +1 to not use Travis by default

[leofang]

Travis is too flaky. Green in PRs does not guarantee green in the main branch. I'd argue we just remove Travis support... but if it's not an option, making it opt-in it is.

[beckermr]

@jaimergp where is the list for cirun?

[jaimergp]

We don't have any yet. We need a mechanism for this though, and I'd be happy to work on this as a general "get access to opt-in providers" task. The idea is tangentially based on how the PPC/ARM/ARM64 opt-ins have worked.

[jaimergp]

Travis is the only (?) provider offering native ppc64le / aarch64, so it should be offered, but I'd argue it should only allow it as a last resort (if you can't support cross compiled builds).

[hmaarrfk]

travis is useful to test failures due to qemu.

Typically, i find that 1 hour on travis = 6 hours on azure + qemu. So in terms of time "saved", there isn't much if you need "native or emulation".

It would be nice to have it enabled again, even if slowly.

[leofang]

It'd be nice to know why cross-compiling or qemu do not work. For me there's absolutely no saving to run on Travis -- it's simply an illusion that something passes and gets merged, and hours later I come back and discover that it fails for no reason on main, and spend another 12 hours (yes, I agree on the 6x slowdown, and it's 12 because of PR & main runs) to get the deployment done through azure + qemu.

I am not against making it opt-in. But if abandoning Travis is an option, the discussion to make it opt-in would be moot.

[beckermr]

We cannot remove or deprecate travis right now for the record.

[jaimergp]

@beckermr, do we need a CFEP for this general sort of "opt-in CI providers" functionality we are discussing?

[beckermr]

It's right on the threshold for sure. We removed circle and drone without a cfep but the infrastructure here is bigger. The security and systems subteam also has some purview here potentially and that activity needs to advise and work with core but no cfep.

[h-vetinari]

Just saw the following banner on a travis build:

Builds have been temporarily disabled for public repositories due to a negative credit balance. Please go to the Plan page to replenish your credit balance or alter your Consume paid credits for OSS setting.

[jaimergp]

We have been granted a NumFocus SDG to work on opt-in CI features in conda-forge, so hopefully we can make this work soon!

[jaimergp]

With the recent work in admin-requests (thanks @aktech, @isuruf!), we can finally proceed with this. IOW, disable Travis by default for new feedstocks, and document how users can request access for non x64 archs.

WDYT @conda-forge/core?

[beckermr]

I'd say LGTM.

[jakirkham]

...document how users can request access for non x64 archs

Has this already been done somewhere?