Automatically build and upload binaries on release #1743
Merged
Conversation
This file contains 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
ichard26
added
C: cleanup
cooperlees
approved these changes
Oct 13, 2020
ichard26
force-pushed
the
self_contained_binary_workflow
branch
2 times, most recently
from
f33134a
to
31b057b
Compare
This commit adds a new GitHub Actions workflow that builds self-contained binaries / executables and uploads them as release assets to the triggering release. Publishing a release, drafting one doesn't count, will trigger this workflow. I personally used GitHub Actions only because it's the CI/CD platform(?) I am familiar with. Only Windows and Linux binaries are supported since I don't have any systems running Mac OS. For Linux, I had originally planned to use the manylinux2010 docker image the PyPA provides for highly compatible wheel building, but unfortunately it wasn't feasible due to GitHub Actions and PyInstaller incompatibilities. As a stopgap the oldest versions of Linux and Windows are used although Windows Server 2019 isn't that old nor is Ubuntu 16.04! I guess someone (maybe me) could work out something else if compatibility is big problem. A few things you should know about the workflow: - You don't need to set the `GITHUB_TOKEN` secret as it is automatically provided by GitHub. - matrix.pathsep is used because PyInstaller configuration's format is OS dependent for some reason ... Also it's worth mentioning that Black once had Travis CI and AppVeyor configuration that did the same thing as this commit. They were committed in mid 2018 and worked (somewhat) well. Eventually we stopped using AppVeyor and the refactor to packages broke the Travis CI config. This commit replaces the still existing and broken Travis CI config wholesale. Co-authored-by: Anders Fredrik Kiær <31612826+anders-kiaer@users.noreply.github.com> - Anders told me that I could get the release asset upload URL directly from the github.event.release payload. I originally planned to use bruceadams/get-release to get such URL.
ichard26
force-pushed
the
self_contained_binary_workflow
branch
from
31b057b
to
79a4cc7
Compare
Closed
|
Any chance for a release to have again wheels for black? |
|
We plan on the next release to having wheels. Just have to hope they won't be built in a dirty directory again. |
|
Any timeframe planned already for that release? 👍 |
|
We're trying to target this month, but ideally within a week. No promises though, I don't make those decisions around here. |
noxan
pushed a commit
to noxan/black
that referenced
this pull request
Jun 6, 2021
This commit adds a new GitHub Actions workflow that builds self-contained binaries / executables and uploads them as release assets to the triggering release. Publishing a release, drafting one doesn't count, will trigger this workflow. I personally used GitHub Actions only because it's the CI/CD platform(?) I am familiar with. Only Windows and Linux binaries are supported since I don't have any systems running Mac OS. For Linux, I had originally planned to use the manylinux2010 docker image the PyPA provides for highly compatible wheel building, but unfortunately it wasn't feasible due to GitHub Actions and PyInstaller incompatibilities. As a stopgap the oldest versions of Linux and Windows are used although Windows Server 2019 isn't that old nor is Ubuntu 16.04! I guess someone (maybe me) could work out something else if compatibility is big problem. A few things you should know about the workflow: - You don't need to set the `GITHUB_TOKEN` secret as it is automatically provided by GitHub. - matrix.pathsep is used because PyInstaller configuration's format is OS dependent for some reason ... Also it's worth mentioning that Black once had Travis CI and AppVeyor configuration that did the same thing as this commit. They were committed in mid 2018 and worked (somewhat) well. Eventually we stopped using AppVeyor and the refactor to packages broke the Travis CI config. This commit replaces the still existing and broken Travis CI config wholesale. Co-authored-by: Anders Fredrik Kiær <31612826+anders-kiaer@users.noreply.github.com> - Anders told me that I could get the release asset upload URL directly from the github.event.release payload. I originally planned to use bruceadams/get-release to get such URL.
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.
Resolves #1669.
https://github.com/ichard26/black/actions/runs/340608417 and https://github.com/ichard26/black/releases/tag/test_binary_action3 shows the workflow in action.