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

[jenstroeger]

Closes https://github.com/jenstroeger/python-package-template/issues/542

However, this new make target does not consider — in a way even duplicates! — how the Action workflows proceed. Unless we consider PR https://github.com/jenstroeger/python-package-template/pull/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

https://github.com/jenstroeger/python-package-template/blob/f8d7a1872d350ae6805b1cceac21fe80f63292e8/Makefile#L210

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

[behnazh]

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]

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.