Skip to content

windows: Publish executables from Appveyor builds available (v2) #6055

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

windows: Publish executables from Appveyor builds available (v2) #6055

wants to merge 4 commits into from
+142 −72

Conversation

stinos
Copy link
Contributor

@stinos stinos commented May 18, 2020

Alternative version for #6049.

This would make downloads of latest build available at https://ci.appveyor.com/project/dpgeorge/micropython/build/artifacts (see https://ci.appveyor.com/project/stinos/micropython/build/artifacts for example) or latest master at https://ci.appveyor.com/project/dpgeorge/micropython/branch/master/artifacts or for direct download (also curl) https://ci.appveyor.com/api/projects/dpgeorge/micropython/artifacts/mpy-cross/mpy-cross.exe etc.

I like this one better than #6049, not only because the downloads are now easily accessible but also because the complete CI build is one script which can be used locally.

@dpgeorge dpgeorge mentioned this pull request May 21, 2020
Closed
@stinos stinos force-pushed the appveyor-rewrite branch 2 times, most recently from 2c936f9 to 965277a Compare May 28, 2020 06:49
@dpgeorge
Copy link
Member

@stinos this looks good to me. Can you please rebase on latest master? Then it should be good to merge.

@stinos
Copy link
Contributor Author

stinos commented Jan 23, 2022

Sure. Should be pretty useful. Will need a bunch of changes to match latest appveyor.yml.

However my first thought when seeing this now: there should be a separate script for the build. I need to make such script anyway so I can test locally, so seems silly to then copy-paste all of that back into Appveyor. Ok to add a ports/windows/build.ps1 ?

@dpgeorge
Copy link
Member

Ok to add a ports/windows/build.ps1

yep

@stinos stinos mentioned this pull request Jan 24, 2022
Closed
stinos added 4 commits January 27, 2022 11:38
@stinos
mpy-cross/Makefile: Add install and uninstall targets.
94958b8 
Use PREFIX/BINDIR per GNU Coding Standards' Makefile Conventions.
@stinos
windows/Makefile: Add install and uninstall targets.
6be5a49 
Use PREFIX/BINDIR per GNU Coding Standards' Makefile Conventions.
@stinos
windows: Use a build script and one single job for Appveyor builds.
a57b866 
This doesn't change what gets built, but in comparison with using
multiple jobs has some advantages:
- the script can be used locally as well
- less complex Appveyor configuration
- using one job leads to faster CI builds because firing up jobs
  costs time and involves a git clone for each
- using one job leads to all build output (including future artifacts,
  see upcoming commit) being reachable via one URL
@stinos
windows: Publish 64-bit executables built by Appveyor.
85d1f36 
This makes the micropython and mpy-cross executables, both from
msvc and mingw ports, avaiable for download:
- ci.appveyor.com/project/<user>/micropython/build/artifacts for the
  last build
- ci.appveyor.com/project/<user>/micropython/branch/<branch>/artifacts
  for the last build of a apecific branch
@stinos
Copy link
Contributor Author

stinos commented Jan 27, 2022 •
edited
Loading

Now up for review; a bit more involved than earlier, mainly because we now have variants and because I wanted to remove the principle that getting the correct executables published depended on the build order, that's just too brittle.

Some additional info:

  • the install targets in the Makefiles are there so the executables built can be put in a dedicated known location, such that after 2
    consecutive builds the output is still accessible whereas the mpy-cross.exe/micropython.exe in the root is the result of the last build only. Also easier to compare different builds. Not needed for msvc builds since they have separate outputs already, and just copy that to the root at the end of the build.
  • the sometimes rather silly function names in Build.ps1 are just to follow the Powershell conventions which static analyzers otherwise complain about. But I'm fine with changing that to BuildMsvc and TestMingw etc if it looks too weird
  • 2 last commits could be 1, but are split to make it clear what it takes to get Appveyor artifacts working
  • build log is larger now, but is split up with detailed VERBOSE: ... lines for each distinct build/test run
  • build time is down from ~14minutes to ~9minutes
  • result can be seen by clicking 'Details' next to 'continuous-integration/appveyor/pr ' in the 'checks' for this PR, then click on the 'Artifacts' tab

@dpgeorge
Copy link
Member

dpgeorge commented Feb 8, 2024

Sorry this got lost. And now with the move from AppVeyor to GitHub Actions it would need to be redone... that's not a priority and I'll leave this PR open as a reminder for whoever wants to do it.

@stinos
Copy link
Contributor Author

stinos commented Feb 9, 2024

No worries; if this is converted to Github CI what should the principle be? Use whatever standard functionality the CI provides? Is there an example for other ports?

@Gadgetoid Gadgetoid mentioned this pull request Feb 29, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
port-windows
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@stinos @dpgeorge