-
Notifications
You must be signed in to change notification settings - Fork 12
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
Comments
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. |
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:
|
ok great! let me think about these options more! Let's default to a release based workflow on github. 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? |
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. |
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. |
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). |
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. 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! |
The current release.yml file is triggered when a tag is pushed to a repo.
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.
The text was updated successfully, but these errors were encountered: