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

Automate Release Process + Provenance #2606

Open
elliot-huffman opened this issue Aug 9, 2024 · 5 comments
Open

Automate Release Process + Provenance #2606

elliot-huffman opened this issue Aug 9, 2024 · 5 comments

Comments

@elliot-huffman
Copy link

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
By automating the release process, it will eliminate risk that the release process won't be followed and the release.md doc can be automated. (see this workflow as an example of what could be implemented for automation).

It also introduces support for NPM provenance. Provenance is a system in NPM that attests the build process and ensures that what you see is what you get, by process reducing risk via proving that an un-known actor is unable to execute in the shadows. Attestation is a way to prove package health via correlation of published package to GH Actions publish command execution via cryptography.

By shifting the release process from local computers to a GH Actions instance, it also reduces risk from a threat actor or malware that is present on the machine that is publishing.

Describe alternatives you've considered
Keeping everything the same?

Additional context
NPM Docs:
https://docs.npmjs.com/generating-provenance-statements

@elliot-huffman
Copy link
Author

I am willing to make a PR for the above.

@fatso83
Copy link
Contributor

fatso83 commented Aug 9, 2024

Thank you for volunteering to follow up on your suggest, Elliot! Very much appreciated. Automated releases has been wanted for at least the last six years (#1657, for reference), but lack of actual manpower to do bigger tasks like this is the main blocker.

One suggestion was to try out the process on one of the smaller projects (like fake-timers, samsam, etc). That was mostly in relation to semantical releases, to try and get a feel for it, but you are in no way obliged to figure out how to do that, although I think it's not that much additional overhead.

In any case, before going into doing the work, it would be nice if you could elaborate on how you envision the release process to work. A new release for every commit (not that nice, IMHO, if I just update the README), magic markers (like [release]) in the commit message, or something else.

@fatso83
Copy link
Contributor

fatso83 commented Aug 9, 2024

And I might add that I have done release "ooops"'s more than once, so automation is very much wanted:

  • forgot pushing the commits and tags after running the release script and publishing to NPM
  • released patch versions (instead of major) after failing to see I committed work with "breaking" in the commit message

🤡

@elliot-huffman
Copy link
Author

Do you have a MS Teams account? I would love to hop in a call with you to deep dive :-)

@fatso83
Copy link
Contributor

fatso83 commented Aug 10, 2024

I'll send you an email using the email on your profile

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

No branches or pull requests

2 participants