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

request: release workflow on GitHub and follow PyPA and PyPI security recommendations #48

Open
lwasser opened this issue Oct 30, 2024 · 7 comments · May be fixed by #73
Open

request: release workflow on GitHub and follow PyPA and PyPI security recommendations #48

lwasser opened this issue Oct 30, 2024 · 7 comments · May be fixed by #73

Comments

@lwasser
Copy link
Member

lwasser commented Oct 30, 2024

The current release.yml file is triggered when a tag is pushed to a repo.

name: CD

on:
  push:
    tags:
    - '[0-9]+.[0-9]+.[0-9]+'
    - '[0-9]+.[0-9]+.[0-9]+(a|b|rc|post|dev)[0-9]+'

I'd prefer that we suggest a on release workflow that looks more like this

being able to cut a release from the GitHub interface is really valuable for a maintainer team!
having a trusted envt setup with pypi is also really nice to have

can we work on adjusting some of this CI build to follow the workflows we are already using in the pyos org! happy to discuss it more as well :) i know there are many different options here. this is not urgent - we will use the template as it is--because it is awesome--tomorrow 🚀 We can also potentially skip the sigstore step as that is a bit more complex to setup and trusted publisher i think is a great first step to teach scientists.

@Midnighter
Copy link
Contributor

The release workflow as is already assumes that you will configure your repo on PyPI with a trusted publisher. I don't see anything else we can do on the template side for that.

As for releases, I work on the command line as much as possible. To me it is really convenient to just push a tag and that triggers a release. I can see that your preferred workflow is also convenient. I'll look into it.

@Midnighter
Copy link
Contributor

I definitely like the automated signing of artifacts in the workflow that you linked. That will be a nice addition. We could also create two workflows:

  1. One (optional via template choices) that runs on tags and only makes a GitHub release.
  2. Another that triggers on releases and then publishes the package(s).

@lwasser
Copy link
Member Author

lwasser commented Oct 30, 2024

ok great! let me think about these options more!
for a maintainer team, having a release workflow that is github based has been a huge time saver (atleast for us!). Please note, that I worry about introducing too many options to our template. This is one of the challenge with other templates!

Let's default to a release based workflow on github.
What we could do however is have a documented option of how to setup a tag based release because I really see your point about how you like to work at the CLI.

Then let's consider as a community, whether we want to add a second release option when the user selected the "fully customized" version of the template (weighing the value of options with the challenge of people being overwhelmed my options!)

does that sound reasonable to you?

@Midnighter
Copy link
Contributor

I agree to try limiting choices and that releases via GitHub is a good default. (I have less experience with other platforms on this.)

I don't know if we need to introduce environments. That seems a feature that only larger community projects need.

@blink1073
Copy link
Contributor

I think that since the PyPA does recommend environments we should include them in the template with a note that they are recommended but not required. My preference would be to only include the workflow_dispatch version, and leave the command line option as an advanced use case that they can manually swap out.

@lwasser
Copy link
Member Author

lwasser commented Nov 6, 2024

that is my preference as well @blink1073 !! i like the idea of documenting the advanced option once we build out docs but having the workflow_dispatch on release be a default as it also teaches good practices associated with releases, tags etc! we taught that last week and everyone picked it up (as far as i could tell it was intuitive once they got the difference between a tag and a release name).

@lwasser
Copy link
Member Author

lwasser commented Jan 8, 2025

Ok, friends. I want to followup on this, i've been working with some of the PyPI folks and also saw how teaching packaging went. I want to update our release workflow to follow pyosmeta.

Below is our security blog.
pyOpenSci/pyopensci.github.io#538

I think releases on GitHub are best for maintainer teams - they work well for our maintainer team and are easy to teach. For many, git and command line can be a scary first step but we've had great success with teaching release based workflows. i'm going to submit a pr to fix our current release workflow to follow what pyosMeta does which has been reviewed by some of the security folks! Trusted publisher is the way to go!

@lwasser lwasser changed the title request: release workflow on GitHub request: release workflow on GitHub and follow PyPA and PyPI security recommendations Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants