Skip to content

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

Closed
wants to merge 1 commit into from

Conversation

stinos
Copy link
Contributor

@stinos stinos commented May 16, 2020

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 like https://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 like https://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.

@dlech
Copy link
Contributor

dlech commented May 16, 2020

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.

https://help.github.com/en/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts

@askpatrickw
Copy link

If this is merged, let me know the final URL to get the build and I'll update the docs with that information.

@dpgeorge
Copy link
Member

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...?

@robert-hh
Copy link
Contributor

That's a good approach. Please include the we executables of mpy-cross too.

@stinos
Copy link
Contributor Author

stinos commented May 21, 2020

https://micropython.org/download,

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.

mpy-cross.exe available in a PyPI package

Yes that's the case, they're from Gitlab builds IIRC. Could be switched, not sure if needed.

Please include the we executables of mpy-cross too.

That's the case already, both 32bit and 64bit.

@andrewleech
Copy link
Contributor

andrewleech commented May 21, 2020

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
My win32/64 builds are done with mingw rather than msvc, so as far as official windows builds go the appveyor builds are more true to the win32 port in many ways.

@stinos
Copy link
Contributor Author

stinos commented May 22, 2020

Just to clarify: the executables from Appveyor will be both the msvc and mingw ones

Capture

@stinos
Copy link
Contributor Author

stinos commented Jan 24, 2022

Closing in favor of #6055 .

@stinos stinos closed this Jan 24, 2022
@stinos stinos deleted the appveyor-artifact branch January 24, 2022 12:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants