It might make sense to port the wheel building CI away from a combination of CircleCI/Appveyor, for a couple of reasons:
GitHub actions supports all three platforms (Windows/MacOS/Linux), avoiding the need to split the CI between numerous services.
The Appveyor account used is my personal account, so other members of development team are unable to modify the settings or manage builds.
In addition, we could also set up continuous deployment; when a new GitHub release is made, the wheels could be automatically built, tested, and uploaded.
It is worth starting from the GitHub Action workflow used over in the PennyLane-Lightning repo:
It might make sense to port the wheel building CI away from a combination of CircleCI/Appveyor, for a couple of reasons:
GitHub actions supports all three platforms (Windows/MacOS/Linux), avoiding the need to split the CI between numerous services.
The Appveyor account used is my personal account, so other members of development team are unable to modify the settings or manage builds.
In addition, we could also set up continuous deployment; when a new GitHub release is made, the wheels could be automatically built, tested, and uploaded.
It is worth starting from the GitHub Action workflow used over in the PennyLane-Lightning repo:
Continuous integration:
PennyLaneAI/pennylane-lightning#subdirectory=.github/workflows/wheels.ymlContinuous-deployment: https://github.com/PennyLaneAI/pennylane-lightning/pull/43
One big question mark is the performance --- GitHub actions might be slower than our current combination of CircleCI/Appveyor.