-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
changes in travis's build environment #8239
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ci/travis/test_script.sh
Outdated
echo PYTHONHASHSEED=$PYTHONHASHSEED | ||
|
||
echo The following args are passed to pytest $PYTEST_ARGS $RUN_PEP8 | ||
if [[ $USE_PYTEST == false ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just remove this outer 'if ..' block and the USE_PYTEST env ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My travis knowledge is very limited and I am not sure to understand what you are suggesting. Can you point me towards more details?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@anntzer Indeed, the documentation doesn't build on 2.7 anymore. |
Well that was caught by you organizing the docathon -- I would never have tried it myself :-) |
We still have a huge backlog on appveyor. Merging this PR would help on that matter. Long term, I agree with Thomas that we should just improve our test coverage, but I think we need to take baby step on this. I am also attempting to see if we could use circle ci to build the documentation which should help us reduce the number of travis build (though appveyor seems to be the pain point right now). |
@NelleV TBH, all these CI tools and servers work are a kind of black magic to me. But what strikes me looking at the scripts is that we have a lot of Python 2.7 builds (~ half of the total amount of builds), which seems almost too many when compared to the diversity of Python 3.3+ that should be tested too. If we allow failure of a Python 2.7 build, “simply” because of the doc, wouldn't it be kind of wasting ressources that could have be used to test stuff on a Python 3 branch? As I wrote in another thread, I am rather confident that #8165 makes the docs to build again on 2.7 (at least on CentOS 7, it just works© on my local branch). So depending on how urgent it is to clear the queue of CI builds, I would almost suggest to temporarily drop the idea of building the docs on 2.7 in favor of a build that would be more useful about making this queue empty. And I guess we could give another try about building the docs on 2.7 when it will be less a rush for CI ressources. On the other hand, one of my main concern if we were dropping the doc build on 2.7, is that documentation is about to change a lot in a very near future (it's the docathon tsunami :) ), so it may still be relevant to check that the docs build both on Python 2 and Python 3. |
The fact that our documentation didn't build under 2.7 for 2 weeks should raise red flags. I am also not convinced that in terms of users, we have such a big difference in 2.7 users and 3 users. My PhD institute, for example, still runs everything by default under 2.7. On the other hand, we have very little developer under 2.7, which explains how we've missed the broken build on 2.7 These are my 2 cents. I do think it is a major problem that our ci tools take that long to build, so reducing the number of builds in general is important (hence moving documentation build to circle-ci). We shouldn't wait 24 hours to get the results. We could blame the docathon for this, but we didn't have such an increase of developers this week. I am quite worried what it means for our next SciPy sprint. We could also decide to build the documentation only on 3.5, and keep the 2.7 for a nightly build on master only. |
Relating to this, I think we should move the mac osx build to a nightly (ie one per day) build on master and maintenance branch, and not doing it at merge nor on PRs. It's very unreliable. |
I agree about OSX. I love using Travis, but on my other projects there is absolutely no way I'm waiting for that build queue to see about my PRs. |
👍 to moving 2.7 docs to nightly, tentative 👍 to moving OSX. What does the reporting on the success/failure fo the periodic jobs look like? |
If you want to be notified, you need to have email notifications. Otherwise, it just shows up as another build in the history. |
I'll investigate this. I think we need to make sure that our CI scales up for the scipy sprint: it is a shame to be slowed down because of our CI tools :) |
None of what I was proposing is going to work out of the box. I suggest we leave it as is for now and see if it helps with the travis and appveyor queue. |
Restarted the 2.7 doc build now that #8165 was merged. |
This is a small refactoring of travis's build environments as well as:
This is still work in progress.
refs #8232