Starting items/questions

[andyfaff]

For discussion:

• a gitattributes to set all line endings to LF
• a GH workflow to use black from the get-go to enforce python style.
• clarify whether the workflow_flow dispatch item allows you to choose where code is uploaded to (the option)
• at the moment the wheel build is fail-fast:false. ATM I think this means that one of the wheel matrix entries can fail, but if it's in a PyPI release run then the ones that did succeed will upload, meaning that we're missing one or more wheels. I think it would be better to have fail-fast:true?
• when we want to make a release presumably there's already been a branch made. At release time is a commit is made to set SOURCE_REF_TO_BUILD to the tag name on the release branch?
• Can we have another input question on workflow_dispatch to ask for the branch/tag name to build? i.e. instead of having to set SOURCE_REF_TO_BUILD in a commit. That branch/tag is then checked out.
• I'm not sure that all the wheels are uploaded in one batch. Consider putting all wheels in one location. e.g:

# in the wheel build entry
-uses: actions/upload-artifact
 with:
   name: wheels-${{ matrix.python }}-${{ matrix.buildplat[1] }}-${{ matrix.buildplat[2] }}
   path: ./dist/*.whl   # location of where the wheels are built
 
# in upload entry. this step followed by PyPI upload.
- uses: actions/download-artifact
  with:
    pattern: wheels-*
    merge-multiple: true     #  downloads the entire set
    path: dist

• the upload to PyPI action should check that you've just built a tag before it makes a release.

[rgommers]

a GH workflow to use black from the get-go to enforce python style.

There's only 50 lines of Python code in a single file in this repo (which black is already happy with) and I don't expect that to grow by much, so I'd prefer to keep things simple and don't add a CI check for this.

at the moment the wheel build is fail-fast:false. ATM I think this means that one of the wheel matrix entries can fail, but if it's in a PyPI release run then the ones that did succeed will upload, meaning that we're missing one or more wheels. I think it would be better to have fail-fast:true?

Uploads are gated on a manual action, nothing will upload beforehand. If a new commit is pushed, the finished jobs on the old commit are discarded. If the release manager chooses to re-run a failed job, for example in case of a single flaky test, the release can proceed unchanged if the job passes. So I think fail-fast: false is useful for the same reason as on the main numpy repo: seeing all failures at once, so you can assess better what is going wrong. All jobs aborting on a single failure makes that hard.

when we want to make a release presumably there's already been a branch made. At release time is a commit is made to set SOURCE_REF_TO_BUILD to the tag name on the release branch?

Yes indeed. That is described briefly in https://github.com/numpy/numpy-release?tab=readme-ov-file#branches-and-tags, but we still need more extensive "how to do a release" docs (Chuck also asked for that). That should explain this in more detail.

Can we have another input question on workflow_dispatch to ask for the branch/tag name to build? i.e. instead of having to set SOURCE_REF_TO_BUILD in a commit. That branch/tag is then checked out.

This could be useful for testing indeed (not for releasing though). Maybe the most useful thing is to be able to give it a PR number and/or a branch on a fork, so it becomes very easy to test a PR on the main repo. I don't think I've seen that capability elsewhere before, but it seems quite useful. I test wheel builds on my fork all the time, and editing branch name, skip conditions, etc. is a bit of a chore.

I'm not sure that all the wheels are uploaded in one batch.

That is already done exactly in the way you suggest:

numpy-release/.github/workflows/wheels.yml

Lines 253 to 262 in 51cd16e

	- name: Download sdist and wheels
	uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v.4.3.0
	with:
	path: dist
	- name: Publish
	uses: pypa/gh-action-pypi-publish@76f52bc884231f62b9a034ebfe128415bbaabdfc # v1.12.4
	with:
	print-hash: true
	attestations: true

the upload to PyPI action should check that you've just built a tag before it makes a release.

I see you opened gh-3 for that, thanks.

[rgommers]

Can we have another input question on workflow_dispatch to ask for the branch/tag name to build? i.e. instead of having to set SOURCE_REF_TO_BUILD in a commit. That branch/tag is then checked out.

This is the one thing that is still actionable. I'll open a follow-up issue for that and close this. It's probably less important now that we have wheel jobs running in the main repo in CI by default. However for larger changes it could be nice to have a GUI way to build a full set of wheels for a PR on the main repo or a branch on a fork.

[rgommers]

https://numpy.org/devdocs/dev/releasing.html got a full update as well, and we've done the 2.3.3 release with this repo, so I'll close this as completed.