Try to get Travis working, again

conda-forge / rust-feedstock

A conda-smithy repository for rust.

BSD 3-Clause "New" or "Revised" License

7 stars 28 forks source link

Try to get Travis working, again #137

Closed pkgw closed 1 year ago

pkgw commented 1 year ago

See discussion in #134. The default/recommended technique for avoiding Travis CI timeout errors seems fail reliably in the deployment builds (but not in PRs, annoyingly!).

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number — package contents not modified
[x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

conda-forge-webservices[bot] commented 1 year ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

pkgw commented 1 year ago

OK @conda-forge/rust, here is yet another PR to try to get Travis working. The previous attempt, #135, worked fine in the pull request, but failed consistently in the deployment builds (that is, builds of the main branch). As summarized in #134, it looks like there is some interaction between the recommended way to address Travis CI timeouts and the multi-arch builds in the deployment mode, which causes the timeout mechanism not to work. So, in this pull request, we implement a similar scheme in a simpler way that will hopefully continue working in the deployment mode.

pkgw commented 1 year ago

I think the only way to see whether this approach will really work is to go ahead and merge it and see what happens, so that's what I'll do.