-
Notifications
You must be signed in to change notification settings - Fork 207
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
Disable a couple of CI builds #2102
Disable a couple of CI builds #2102
Conversation
…it to generate python35 wheels for new releases.
Isn't it possible to run the disabled builds only on release instead of having to comments and uncomment the code manually? |
I did look at it and could not a way to do but a 2nd iteration on this may be working! ;) For reference: |
Could you create a tag in your repo (if we do it in this one it'll create a DOI in zenodo) to test if it's really working? |
Yes, it works: |
Isn't it possible to do the same in travis? |
e5309bd
to
8451306
Compare
At the moment, the appveyor build takes more 2h to complete, because we are testing 6 different builds and there are run sequentially. The situation is significantly with travis, which is running 5 builds at the same but I would also suggest to disable the python 3.5 and python 3.6 mac osx build to save CI time.
The idea is to continuously test python 3.5 and python 3.6 support with linux and to other disable build for a release when the build will be enabled to generate the wheels. This should be a good compromise between testing across different platform and python version and saving CI time.
On a side node, conda-forge is not packaging for python 3.5 anymore (only python 3.6 and python 3.7).
Progress of the PR