-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
RFC windows: Publish executables from Appveyor builds available #6049
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
Conversation
FYI, GitHub Actions allows uploading CI artifacts. It would be a bit of a chore to convert travis and appveyor to github actions, but then artifacts from all builds could be quite easily accessible to everyone. I've done this on a few private repos so far and have been quite happy with how it works. |
If this is merged, let me know the final URL to get the build and I'll update the docs with that information. |
Yes I think it'd be good to provide Windows builds in some way. Note that firmware is built automatically every 12 hours (by a custom server) and put on https://micropython.org/download, so maybe it makes sense to put these executables there so everything is in the one place? It would be able to track releases and master/unstable. Also I think @andrewleech already has mpy-cross.exe available in a PyPI package...? |
That's a good approach. Please include the we executables of mpy-cross too. |
Ok, didn't think of that. How do the files get there, FTP? Appveyor can deploy automatically to that so I could add the placholders for doing so already, you'd then have to configure your instance by adding credentials as a variable somewhere.
Yes that's the case, they're from Gitlab builds IIRC. Could be switched, not sure if needed.
That's the case already, both 32bit and 64bit. |
Yep my mpy-cross builds are from https://gitlab.com/alelec/mpy_cross which does regular master builds and tagged builds, wraps the mpy-cross binaries in a simple python package and automatically pushes the releases up to pypi (linux, osx, win). It's completely hands off so it's costing me nothing to keep it doing it's own thing. That being said I'm always open to suggestions to change/redirect it in any way for the good of the overall ecosystem. Irrespective of that, I agree it'd be useful to have builds on https://micropython.org/download |
Closing in favor of #6055 . |
This makes Appveyor store the micropython and mpy-cross executables (both msvc and mingw versions) so they become available for download. Unfortunately they are currently not available via a simple permalink (or I'm missing something) because the build is split in jobs and each job has it's own artifacts.
Suppose this gets merged as-is, then if you visit
https://ci.appveyor.com/project/dpgeorge/micropython/branch/master
you can click on one of the jobs there, then click 'Artifacts' and get a list of downloadable files. Alternatively a link likehttps://ci.appveyor.com/api/projects/dpgeorge/micropython/artifacts/ports/windows/build/Releasex64/micropython.exe?branch=master&job=Configuration%3A%20Release%3B%20Platform%3A%20x64
does give direct access to a file so such links can be used in e.g. quickref.rst or the README. (Just to be clear: above links currently don't do anything, just an example of what they would be).Alternatively I can change appveyor.yml to only have one job which builds all different versions. That's pretty easy and then a link like
https://ci.appveyor.com/project/dpgeorge/micropython/branch/master/artifacts
would directly show the artifacts and the direct links also become simpler.Next step could be to publish these to Github itself. For instance to always provide the latest master build I think it's possible to make a release on github with a fixed name like
trunk
, and Appveyor can then automatically deploy the executables from the last build to that release. This would be neat because we can simply tell people to go to something likehttps://github.com/micropython/micropython/releases/download/trunk/micropython-msvc.zip
to grab the latest build. But that only makes sense if we do the same for some of the Travis builds as well, e.g. also have Travis upload the latest unix executables to that release.