BUILD: Upload wheels to anaconda,org#20890
Conversation
| elif [ "schedule" == "${{ github.event_name }}" ] || [ "workflow_dispatch" == "${{ github.event_name }}" ]; then | ||
| echo scheduled or dispatched event | ||
| echo "ANACONDA_ORG=scipy-wheels-nightly" >> $GITHUB_ENV | ||
| echo "TOKEN=${{ secrets.NUMPY_NIGHTLY_UPLOAD_TOKEN }}" >> $GITHUB_ENV |
There was a problem hiding this comment.
@bashtage I used ${{ secrets.NUMPY_TOKEN }} here like elsewhere in this repo where you used $NUMPY_TOKEN. I wonder if it makes a difference?
|
Maybe it's better to wait for all wheels to be present before uploading wheels. Uploading wheels from here would also mean stopping the numpy-wheels uploads, so it might not be ideal if some wheels are missing. (P.S. can you append [wheel build] to your next commit so that the wheel builder triggers and we can see if the workflow works?) |
Those wheels should come from the travis action, like in numpy-wheels which uses azure for x86 / macOS builds and travis for aarch64. I think the proper order would be:
Then subsequent PRs can deal with aarch64 and travis. |
|
The wheel build run finished, it reports non-dispatch event when decided whether to upload or not. |
|
The intermittent PyPy38 windows failure will be fixed by the next release, which should happen in the next few weeks. See https://foss.heptapod.net/pypy/pypy/-/issues/3604 |
|
We should filter out the dummy tag for starting a new branch (like |
|
Does this skip uploading duplicate builds? That can be handy when a build fails for unrelated reasons and needs to be rerun. Github actions doesn't allow us to selectively rerun a build. Hmm, makes me wonder if there is a way to break things up so that that is possible. |
No, like the current numpy-wheel runs on Azure, the entire build can be rerun but individual wheel builds cannot, and any new upload will replace and older one with the same name. |
|
If you upload a dupe to Anaconda it just overwrites the previous daily that will have the same git hash and other descriptors. |
|
Tags that end with |
Ah, you use |
Maybe we can make the uploading to the staging area based off another commit trigger. |
How common is this? I think changing tags is discouraged as an anti-practice. It would be better to liberally use release candidates, then re-tag the last release candidate with the release tag once everything is OK.
I would prefer to put this in as-is (and fix the inevitable problems with tokens and uploading) and if needed in a future PR we can add more features. |
Changed to use |
Typos happen :) That said, it may be that adding an empty commit for a new tag might be the best solution. I do tend to think of the release branch as my private preserve. |
Rightly so. I think |
Might just have them on different days (Wed and Sat) and we can compare before disabling the numpy-wheels build. |
|
@charris thoughts? |
|
Let's just put this in, I don't see any reason to worry about multiple nightly uploads. |
|
Thanks Matti. |
|
There hasn't been a wheels upload to the nightly repo. I think that should have happened? |
|
Let's see, I pushed the button "Run workflow" on https://github.com/numpy/numpy/actions/workflows/wheels.yml. |
|
Ahh, indeed, something is wrong. The "Upload wheels" build step was not triggered from this scheduled run, but it is printing "scheduled or dispatched event" in the "Set Upload Variables" step. The condition |
|
fixed in PR #20996 |
Fixes #20262
Upload wheels to anaconda.org via cibuildwheel. The logic is:
This uses the secret tokens which were generated from https://anaconda.org/multibuild-wheels-staging/settings/access https://anaconda.org/scipy-wheels-nightly/settings/access and then added to this repo at https://github.com/numpy/numpy/settings/environments/231368784/edit
This will probably influence the release instructions
I tested this in my fork of the repo. The commit ref is echoed in the Get commit message step (open the "Get commit message" fold in the CI run area to see the temporary tag in my fork of
refs/tags/v2.0.1.dev0. Then this causes "push and tag event" to be echoed from the appropriate branch of theifin the "Setup Upload Variables" fold in any of the wheel builds, which will set up the$TOKENand$ANACONDA_ORGto be appropriately set.The use of the secrets and final upload step should Just Work(tm) but may require some tweaks.
Thanks to @bashtage for the parallel work done in MacPython/statsmodels-wheels#97
@lithomas1 - does this look right?
Along the way, I also added
if: github.repository == 'numpy/numpy'to some other workflows so they do not run on forks.