Closed jakirkham closed 7 years ago
CircleCI is a pretty good option I'd say. I don't think there was a reason I didn't do this before - other than the fact that TravisCI was convenient. 👍
I think Travis CI is still processing a backlog from yesterday's GitHub outage. Though they stated they were ok, one can see they are peaking at 164 builds on the OS X queue with very infrequent drops. I expect this will cause issues with testing and conversion today. Might be worth playing with something to get this working.
Am thinking about taking a partial step in this direction and simply collapsing the matrix on Travis CI. We basically only need one build at a time, but are taking two. Please see PR ( https://github.com/conda-forge/staged-recipes/pull/1234 ) for details.
This remains a pain point. It took ~11hrs for spm1d
to be converted. Admittedly this was because Travis CI has been pretty backlogged. However, it is infrequent that Travis CI is not backlogged. Would be nice to get this onto CircleCI or something else.
cc @jochym
:100:
Yep, with long Travis CI backlogs, this is basically paramount. @pelson, is there some way we can safely share the secure environment variables as they will need to be transferred to CircleCI? The rest is just code, which anyone who has time to can pitch in.
We now run conversion on Travis CI using a Linux worker while still building PRs of recipes on macOS. ( https://github.com/conda-forge/staged-recipes/pull/4178 ) Also it seems like Travis CI's Linux and macOS workers are on different queues. Plus we now auto retrigger any failed conversion jobs. ( https://github.com/conda-forge/staged-recipes/pull/4188 ) Thus we are able to get a fresh log for each retrigger. So I don't think this is very important to pursue any more and will close this out.
Currently we have a lot of issues using Travis CI to do feedstock generation. These range from regular backlogs of Travis CI in the middle of the day. Travis CIs relative slowness compared to other CI services. The fact that Mac and Linux builds share the same queue ( https://github.com/travis-ci/travis-ci/issues/6211 ). So if Mac builds get backed up, so do the Linux builds. Also, it puts us with an unnecessary matrix that may contribute to the slowness and could easily be absorbed into some
if
statement on CircleCI. Finally, as Travis CI restarts the job for the same build ID, we lose the log. This makes it very difficult to go back and figure out what went wrong. Other CIs like CircleCI don't have this problem.One alternative would be to switch to CircleCI for this functionality so it gets absorbed into our existing workers. This would also halve our Travis CI queue. Another alternative would be to use a CI that we don't use for building so it doesn't sit on any queue used for building. While a bit non-ideal for building, Wercker CI or some other CI would fit fine in this role too.