Skip to content

Reduce number of CI builds #8232

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

Closed
anntzer opened this issue Mar 8, 2017 · 17 comments
Closed

Reduce number of CI builds #8232

anntzer opened this issue Mar 8, 2017 · 17 comments
Milestone

Comments

@anntzer
Copy link
Contributor

anntzer commented Mar 8, 2017

Following a discussion with @NelleV I suggest to decrease the number of CI builds to help easing the backlog.

  • drop USE_PYTEST (now useless)

On Travis, e.g.:

  • py2.7 mock numpy=1.7 pandas docs
  • py3.4
  • py3.6 pandas docs pep8 delete-font-cache
  • osx (=2.7) mock

Note that we really should build the docs on 2.7 too (extra points if we build them on OSX instead of the Linux 2.7 job) -- right now they don't build on 2.7 at all (due to failure in examples).

On Appveyor the third job is currently a duplicate of the second(!) except that one has USE_PYTEST and not the other (which is the same). So we could be left with

  • py2.7 numpy=1.8 without extra dependencies
  • py3.5 numpy=1.10 without extra dependencies
  • py2.7 numpy=1.10 32-bit with extra dependencies
    (the last two could be merged into e.g. py3.5 numpy=1.10 32-bit with extra dependencies, if we're still under backlog pressure)

More extra points if someone manages to build the docs on Windows...

@NelleV
Copy link
Member

NelleV commented Mar 8, 2017

So… It seems that USE_PYTEST == false and true do not have the same behaviour.
I am investigating…

@afvincent
Copy link
Contributor

Selfishly I am 👍 for CI build of the docs on Python 2.7 😈. FWIW, I have just successfully locally built the doc on Python 2.7 (and Linux), with #8165 in its current state (eventhough I still have to have a look to a comment @anntzer did on this PR).

@tacaswell
Copy link
Member

I would rather a 3.5 test run than building the docs twice, the docs are just a smoke test (we should improve the test coverage of the validators).

@tacaswell tacaswell added this to the 2.1 (next point release) milestone Mar 8, 2017
@anntzer
Copy link
Contributor Author

anntzer commented Mar 8, 2017

Appveyor covers 3.5.

@NelleV
Copy link
Member

NelleV commented Mar 9, 2017

@afvincent indeed your patch will fix the documentation under 2.7.

@anntzer
Copy link
Contributor Author

anntzer commented Mar 9, 2017

@afvincent @NelleV There's a bunch of other entries in rcsetup.py that check for six.text_types. I have a strong suspicion that most of them should be replaced by six.string_types, otherwise they'll just break in the same way when a non-unicode string is passed in Py2.

@NelleV
Copy link
Member

NelleV commented Mar 9, 2017

Yep, that's the conclusion I came up with.

@afvincent
Copy link
Contributor

I would also be inclined to agree with this conclusion: in #8165 I used six.text_type in first place because it seemed to be used quite a lot to do this kind of checking in rcsetup. And I was bitten rather bad for doing so instead of using six.text_type… However, based on my further experience in #8165, I would advise to be careful with six.string_types too, as it would also let pass strings like "Hello".encode("utf-16") (or with any other weird encoding that does not map smoothly with the ASCII one), which can have some weird/funny/unexpected side-effects too.

@anntzer
Copy link
Contributor Author

anntzer commented Mar 10, 2017

@QuLogic It appears that on a successful build, Appveyor will create a wheel to upload to conda (see appveyor.yml after_test). Perhaps we could save some time by always first building the wheel and then installing the wheel to run the tests? (especially if we don't have a C compiler cache)

@QuLogic
Copy link
Member

QuLogic commented Mar 12, 2017

@anntzer That sounds like a good idea; I'm not sure why it was done this way or why we need to build the wheels every time either. Ping @JanSchulz.

@jankatins
Copy link
Contributor

The wheels are not uploaded, but just placed in the appveyor download "spot". The idea was to have a place where win users can download stuff to try fixes.

@anntzer
Copy link
Contributor Author

anntzer commented Mar 12, 2017

Sure, but they could still be built first and the test installation done using them.

@phobson
Copy link
Member

phobson commented Apr 26, 2017

Quick, related questions: to me it appears that we always use python 2.7 to build the docs, no matter which version of python we've set travis to use: https://github.com/matplotlib/matplotlib/blob/master/ci/travis/test_script.sh#L38

Is that true or am I missing something?

@anntzer
Copy link
Contributor Author

anntzer commented Apr 26, 2017

That's just to run linkchecker.

@phobson
Copy link
Member

phobson commented Apr 26, 2017

Ahh yes, i see it now.

@anntzer
Copy link
Contributor Author

anntzer commented Jul 21, 2017

(But in fact linkcheck is now builtin to sphinx so we don't even need that. See e.g. #5380.)

@tacaswell
Copy link
Member

Closing this as we are now down to:

  • on circleci
    • 3.5 docs
    • 2.7 docs
  • on travis
    • Linux 2.7
    • Linux 3.4
    • Linux 3.6
    • OSX 2.7
  • on appveyor
    • 3.5
    • 3.6

We need to try turning the 2.7 build back on on appveyor and I might try adding a 3.6 build on OSX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants