You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This builds on the discussion which started in #2774.
Currently, building and publishing a new Altair version is a manual process as outlined in RELEASING.md. It involves making sure that various version numbers are properly updated, that you have all dependencies installed locally, building and uploading source and wheel distributions, building and uploading the documentation, adjusting the changelog etc. I'd see the following advantages in using GitHub Action workflows for building and uploading the source and wheel distributions as welll as the documentation:
More reliable build process as it happens in a fresh environment ensuring that the relevant dependencies are installed
More secure as a local build environment might contain malware
Credentials can be shared among maintainers, reducing single-person dependency risk
Automation reduces risk of errors in general and speeds up the process. This would be helpful if we want to have more frequent releases, e.g. for inevitable bug fixes after the first 5.0 release
After implementing it in the Altair repo, I'd suggest to also use similar workflows for the altair companion packages (altair_saver, altair_viewer, etc.) for the same reasons.
Proposal for discussion
To publish a new release, one would still update the version numbers as described in RELEASING.md and add a git tag, e.g. "v5.0.0". As soon as this is pushed to main, the following two new workflows would be executed. So the trigger is "any commit with a git tag starting with "v". As an alternative, these workflows could also be kicked off manually.
build_and_publish_package.yml: Builds the source and wheel distributions for Altair and then uploads them to Pypi. Can follow this pypi tutorial. Also see wheels.yml in the Pandas repo. The build for conda-forge is triggered automatically by the conda-forge bot as is already the case now in the feedstock repo
The relevant credentials could be stored as GitHub Secrets and would be only available to Altair maintainers.
The above process can of course be further automated such as automatically updating version numbers - some packages have much fancier workflows - but maybe it's good to start out simple.
What do you think? Is this helpful? I'm happy to take this on and start a PR but I first wanted to get some input. Also, it requires that the credentials for Pypi are available and access credentials for the docs repo.
The text was updated successfully, but these errors were encountered:
binste
changed the title
Set up build and publish workflows with GitHub Actions
Build and publish package and documentation with GitHub Actions
Jan 1, 2023
Thanks for putting this together, I love the idea of automating this to make it more reproducible and transparent! I don't have any experience of publishing to PyPI via GH actions myself, but from the pandas files you linked, it doesn't seem too complicated (and the altair version of those workflows would likely be a bit simpler). So I am +1 on this, let's see what everyone thinks.
Happy to hear! @mattijn also mentioned in this comment that he thinks this could be an improvement.
@jakevdp In my understanding you are currently the only maintainer with the release credentials. Would the above described approach work for you? If yes, I could implement this already for version 5, which would give clarity on how the upcoming release can be done and especially by whom (i.e. you or one of the other maintainers), see this related discussion. The same goes for the other repos in the altair-viz organisation.
The governance topic is resolved but building and publishing via GitHub Actions is still desirable. Once we get to this, we should look at the recommendations in https://scientific-python.org/specs/spec-0008/
This builds on the discussion which started in #2774.
Currently, building and publishing a new Altair version is a manual process as outlined in RELEASING.md. It involves making sure that various version numbers are properly updated, that you have all dependencies installed locally, building and uploading source and wheel distributions, building and uploading the documentation, adjusting the changelog etc. I'd see the following advantages in using GitHub Action workflows for building and uploading the source and wheel distributions as welll as the documentation:
After implementing it in the Altair repo, I'd suggest to also use similar workflows for the altair companion packages (altair_saver, altair_viewer, etc.) for the same reasons.
Proposal for discussion
To publish a new release, one would still update the version numbers as described in
RELEASING.md
and add a git tag, e.g. "v5.0.0". As soon as this is pushed to main, the following two new workflows would be executed. So the trigger is "any commit with a git tag starting with "v". As an alternative, these workflows could also be kicked off manually.build_and_publish_package.yml
: Builds the source and wheel distributions for Altair and then uploads them to Pypi. Can follow this pypi tutorial. Also see wheels.yml in the Pandas repo. The build for conda-forge is triggered automatically by the conda-forge bot as is already the case now in the feedstock repobuild_and_publish_docs.yml
: Builds the documentation and then publishes it by updating the docs repo. A combination of what is inRELEASING.md
andsync_website.sh
. Also see docbuild-and-upload.yml in the pandas repo.The relevant credentials could be stored as GitHub Secrets and would be only available to Altair maintainers.
The above process can of course be further automated such as automatically updating version numbers - some packages have much fancier workflows - but maybe it's good to start out simple.
What do you think? Is this helpful? I'm happy to take this on and start a PR but I first wanted to get some input. Also, it requires that the credentials for Pypi are available and access credentials for the docs repo.
The text was updated successfully, but these errors were encountered: