Skip to content

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

Merged
merged 5 commits into from
Mar 12, 2017
Merged

changes in travis's build environment #8239

merged 5 commits into from
Mar 12, 2017

Conversation

NelleV
Copy link
Member

@NelleV NelleV commented Mar 8, 2017

This is a small refactoring of travis's build environments as well as:

  • removing the python 3.5 build
  • adding a python 2.7 documentation build environment (our documentation recently stopped building under 2.7).

This is still work in progress.

refs #8232

@NelleV NelleV changed the title DOC changes in travis's build environment [WIP] DOC changes in travis's build environment Mar 8, 2017
echo PYTHONHASHSEED=$PYTHONHASHSEED

echo The following args are passed to pytest $PYTEST_ARGS $RUN_PEP8
if [[ $USE_PYTEST == false ]]; then
Copy link
Member

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 ?

Copy link
Member Author

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@NelleV NelleV changed the title [WIP] DOC changes in travis's build environment [WIP] changes in travis's build environment Mar 9, 2017
@NelleV
Copy link
Member Author

NelleV commented Mar 9, 2017

@anntzer Indeed, the documentation doesn't build on 2.7 anymore.
Nice catch!

@anntzer
Copy link
Contributor

anntzer commented Mar 9, 2017

Well that was caught by you organizing the docathon -- I would never have tried it myself :-)

@afvincent
Copy link
Contributor

Well if one really wants to give credit where credit is due, I would say that @aashil may have been first to report documentation build failure with #8145 😈 .

@NelleV
Copy link
Member Author

NelleV commented Mar 9, 2017

We still have a huge backlog on appveyor. Merging this PR would help on that matter.
What do you guys think about switching the python2.7 build to allow failure temporarily?

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).

@afvincent
Copy link
Contributor

@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.

@NelleV
Copy link
Member Author

NelleV commented Mar 10, 2017

The fact that our documentation didn't build under 2.7 for 2 weeks should raise red flags.
The idea behind not testing python3.5 is that 3.4 and 3.6 should cover any regression in 3.5. We could move some of the environments to only test after merge with master.

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.

@NelleV
Copy link
Member Author

NelleV commented Mar 10, 2017

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.

@dopplershift
Copy link
Contributor

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.

@tacaswell
Copy link
Member

👍 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?

@tacaswell tacaswell added this to the 2.1 (next point release) milestone Mar 10, 2017
@dopplershift
Copy link
Contributor

If you want to be notified, you need to have email notifications. Otherwise, it just shows up as another build in the history.

@NelleV
Copy link
Member Author

NelleV commented Mar 10, 2017

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 :)

@NelleV
Copy link
Member Author

NelleV commented Mar 11, 2017

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.

@NelleV NelleV changed the title [WIP] changes in travis's build environment [MRG] changes in travis's build environment Mar 11, 2017
@anntzer
Copy link
Contributor

anntzer commented Mar 12, 2017

Restarted the 2.7 doc build now that #8165 was merged.

@tacaswell tacaswell merged commit a4cee9d into matplotlib:master Mar 12, 2017
@QuLogic QuLogic changed the title [MRG] changes in travis's build environment changes in travis's build environment Mar 12, 2017
@NelleV NelleV deleted the travis_refactor branch March 13, 2017 16:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants