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

feat(make): add the emergency-release target to locally build and publish a new package release without Github Action workflows #544

Open
wants to merge 2 commits into
base: staging
Choose a base branch
from

Conversation

jenstroeger
Copy link
Owner

@jenstroeger jenstroeger commented May 11, 2023

Closes #542

However, this new make target does not consider — in a way even duplicates! — how the Action workflows proceed. Unless we consider PR #537, trying to lower more workflow jobs into the Makefile would result in running checks and tests too often.

Thought: should we make this target

emergency-release-pypi:

dependent on check test (or just dist) to ensure the package is alright?

@jenstroeger jenstroeger requested a review from behnazh as a code owner May 11, 2023 21:32
@jenstroeger jenstroeger force-pushed the add-emergency-release-target branch 2 times, most recently from 8fb56ed to 92f09cc Compare July 5, 2023 19:52
@behnazh
Copy link
Collaborator

behnazh commented Jul 13, 2023

While I understand the frustration if GitHub goes down, I'm afraid adding this target goes against the SLSA and build integrity principles. I'm not sure if it's a good idea to make manual publishing possible in this repo. But in an emergency case, people can always publish manually if they want to anyway.

@jenstroeger
Copy link
Owner Author

jenstroeger commented Jul 13, 2023

I'm not sure if it's a good idea to make manual publishing possible in this repo.

Manual publishing is already possible just by using

  • make dist to create all distribution files; and then
  • twine upload --verbose --skip-existing dist/*.tar.gz dist/*.whl to upload the artifacts.

Maybe something to raise with the SLSA folks to discuss? How they’d recommend dealing with such a case?

I actually thought about adding a section to the README regarding workflow assumptions — one, the required infrastructre needs to be available and functional (e.g. Github/CI, Sigstore, …); and two, the tools used must be functional and trusted (e.g. commitizen).

The other day we had workflows fail half-way-through because of a bug in commitizen, which meant we could bump the git repo correctly but failed to generate all artifacts.

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 this pull request may close these issues.

2 participants