Add appveyor config back for building windows wheels #2979
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With the recent instability and unreliability with azure-pipelines relying on it to build our windows wheels for the upcoming 0.9 release doesn't seem to be prudent. Especially when considering our ability to create reliable portable wheels for a windows environment manually outside of CI is limited (we've had issues trying to do it manually in the past). This commit adds back our appveyor config for building wheels which has worked well for past releases. This way even if azure fails for us we have a fallback available when we push our release tag.
|
Ok, cool it looks like this still works: https://ci.appveyor.com/project/Qiskit/qiskit-sdk-py/builds/26679248/artifacts we can use this as a fallback for azure being unreliable I'll revert the test patch and remove the on hold |
|
Hmm, it looks like because there are no appveyor jobs that run on non-tag commits here the appveyor section in the checks will just sit as pending. |
The appveyor ci system doesn't like a config with 0 jobs configured to run. If no jobs are configured to run it will sit there forever as pending state. Since we only want to run the wheel build jobs on tags if we only had the wheel jobs in the config this would result in an appveyor entry in the checks on github sitting in a pending state forever. To avoid this problem this commit adds a normal test job that will run python 3.7 job so something will come back. We can safetly ignore this job since it's duplicated with with what we run in azure, but it will at least mean we're not leaving a PR in the pending state forever.
kdk
approved these changes
Aug 14, 2019
faisaldebouni
pushed a commit
to faisaldebouni/qiskit-terra
that referenced
this pull request
Aug 5, 2020
* Add appveyor config back for building windows wheels With the recent instability and unreliability with azure-pipelines relying on it to build our windows wheels for the upcoming 0.9 release doesn't seem to be prudent. Especially when considering our ability to create reliable portable wheels for a windows environment manually outside of CI is limited (we've had issues trying to do it manually in the past). This commit adds back our appveyor config for building wheels which has worked well for past releases. This way even if azure fails for us we have a fallback available when we push our release tag. * Do not merge, verifying it still works * Revert "Do not merge, verifying it still works" This reverts commit 285bfbb. * Upload artifacts even if build fails * Add back one job so it doesn't sit pending forever The appveyor ci system doesn't like a config with 0 jobs configured to run. If no jobs are configured to run it will sit there forever as pending state. Since we only want to run the wheel build jobs on tags if we only had the wheel jobs in the config this would result in an appveyor entry in the checks on github sitting in a pending state forever. To avoid this problem this commit adds a normal test job that will run python 3.7 job so something will come back. We can safetly ignore this job since it's duplicated with with what we run in azure, but it will at least mean we're not leaving a PR in the pending state forever. * Use ps backend for mpl tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
With the recent instability and unreliability with azure-pipelines
relying on it to build our windows wheels for the upcoming 0.9 release
doesn't seem to be prudent. Especially when considering our ability to
create reliable portable wheels for a windows environment manually
outside of CI is limited (we've had issues trying to do it manually in
the past). This commit adds back our appveyor config for building wheels
which has worked well for past releases. This way even if azure fails
for us we have a fallback available when we push our release tag.
Details and comments