Skip to content
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.

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

Build and publish package and documentation with GitHub Actions #2793

Open
binste opened this issue Jan 1, 2023 · 3 comments
Open

Build and publish package and documentation with GitHub Actions #2793

binste opened this issue Jan 1, 2023 · 3 comments

Comments

@binste
Copy link
Contributor

binste commented Jan 1, 2023

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.

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.

@binste 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
@joelostblom
Copy link
Contributor

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.

@binste
Copy link
Contributor Author

binste commented Jan 7, 2023

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.

@binste
Copy link
Contributor Author

binste commented Sep 5, 2024

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/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants