Skip to content

Automated bugfix release #12889

Open
Open

Description

@pllim

@Cadair suggested that maybe we can use https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment to fully automated bugfix releases. For instance, maybe a GitHub comment to trigger bot PR to render towncrier change log, and another comment to push to PyPI, and so on.

cc @astropy/core-release-maintainers

Activity

  1. Cadair commented on Feb 24, 2022

    @Cadair
    Member

    Automate away those pesky bugfixes.

  2. nstarman commented on Mar 7, 2022

    @nstarman
    Member

    Is there something conceptually wrong with linking bugfix release with each bug fix PR? Have the bug label do everything, kind of like the meeseeks backports.

  3. pllim commented on Mar 7, 2022

    @pllim
    MemberAuthor

    A bugfix release with each PR is a little too much. While the release itself might be automated, there is still human overhead in communication and post-release activities. Also, I am not sure if it helps downstream maintainers to have to look out for a new bug fix release several times a week.

  4. mhvk commented on Mar 7, 2022

    @mhvk
    Contributor

    Note that @astrofrog implemented part of this - at least for pyerfa all one has to do is push the relevant tag and the rest is automatic. Or do we have that already for astropy too?

  5. astrofrog commented on Mar 7, 2022

    @astrofrog
    Member

    We already have that for astropy but there are a few steps before/after that are manual.

  6. Cadair commented on Mar 14, 2022

    @Cadair
    Member

    there is still human overhead in communication and post-release activities

    Boooo, automate it all!!

    I think once per PR is probably too much, but getting it to the point where it's basically a human checked cron job (monthly or even weekly?!) should be the goal imo.

  7. pllim commented on Feb 10, 2025

    @pllim
    Author
  8. pllim commented on Feb 24, 2025

    @pllim
    MemberAuthor

    Re astropy/astropy-project#430 (comment)

    @astrofrog , let's move the automated bugfix release convo here since is astropy/astropy-project#430 is about collecting Coordination Meeting discussion topics in general.

    Is your specific ask to split https://github.com/astropy/astropy/blob/main/.github/workflows/publish.yml into 2 workflows: 1 for major release that needs human, and 1 for fully automated bugfix release as a scheduled event?

  9. Cadair commented on Feb 25, 2025

    @Cadair
    Member

    I have been hacking and testing more automated releases on my dkist package. The workflow I have settled on currently (there's still room for more automation) is this:

    • Manually trigger the prepare-release workflow.
    • A Pull Request with the rendered changelog is opened (and any other automated tasks).
    • A Draft GitHub release is made, including the release notes.
    • Merge the PR when ready.
    • Publish the release
    • The regular publish workflow runs.
  10. astrofrog commented on Feb 25, 2025

    @astrofrog
    Member

    Is your specific ask

    To be clear, I don't have any asks - just think it would be interesting to discuss. It would just be worth exploring whether we could make bugfix releases almost completely automatic, so we don't have to think too much about it. To go one step further than what @Cadair is suggesting, we could make it so that at periodic intervals (e.g. every week or every two weeks), a PR is automatically opened to render the changelog, and after a manual review (just to make sure everything is ok) we could merge it and this would automatically trigger a bugfix release. So this would be truly 'one-click' (unless there are issues in the changelog to fix, but these should usually be trivial).

  11. pllim commented on Feb 25, 2025

    @pllim
    MemberAuthor

    If we want to go this route, what about having integration-testing to run against the bugfix RC also, just in case one of the bug fixes break downstream? It won't be the first time we thought we fixed a bug, but someone downstream was treating the bug as a feature, or when we unintentionally broke API/behavior compatibility.

  12. Cadair commented on Feb 25, 2025

    @Cadair
    Member

    That sounds like a good idea, but feels orthogonal? Do we do that on every bugfix manually at the moment?

    Having a "downstream" workflow like gwcs / asdf etc would be a good way of doing that though. We could at least cover coordinated packages (+ sunpy 😉 ) that way?

  13. pllim commented on Feb 25, 2025

    @pllim
    MemberAuthor

    I am just thinking that if it is automated, it is going to happen more often, but perhaps it is also orthogonal.

  14. Cadair commented on Feb 25, 2025

    @Cadair
    Member

    I think it would be a good thing to have a different issue for 😉

  15. pllim commented on Feb 26, 2025

    @pllim
    MemberAuthor

    Yes, I think you are right. When I have time, I can see if I already opened an issue about this somewhere, and if not, put some words together and open one... unless someone beats me to it. Update: astropy/astropy-integration-testing#25

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions