ci: Add nightly canary release for python sdk

[Abhijeet Prasad (AbhiPrasad)]

Similar to the strategy used here: braintrustdata/braintrust-sdk-javascript#1547, this PR adds a github workflow that publishes a nightly canary release for the braintrust package to Test PyPi. Read through docs/publishing.md, it has all the info you need.

We also don't publish github releases or git tags for canaries for now, but we can change that decision at a later date.

We have to do all the publishing from a single workflow because pypi trusted publishing relies on that.

[Cedric / ViaDézo1er (viadezo1er)]

The only annotations are str and int, so what is from __future__ import annotations used for?

[Abhijeet Prasad (AbhiPrasad)]

good catch, fixed with b3c85e8!

[Cedric / ViaDézo1er (viadezo1er)]

mise exec -- python test-publish.py prepare prerelease main --run-number 1
and
mise exec -- python test-publish.py prepare prerelease NOT-A-VALID-REF --run-number 1
have the same behavior.

Meanwhile,
mise exec -- python test-publish.py prepare prerelease --run-number 1
asks for a target_ref

So one might expect mise exec -- python test-publish.py prepare prerelease NOT-A-VALID-REF --run-number 1 checks NOT-A-VALID-REF is a valid ref, but it's not the case.

I think test-publish prepare should:

• test wether the provided ref is valid
• or warn the user the ref isn't tested

[Cedric / ViaDézo1er (viadezo1er)]

--run-number n is manually set by the user, so it's a bit error prone, we might decrement or skip version number.
However I'm not sure the added check needed (probably requires looking at releases on Github and Pypi and maybe a local registry etc...) outweighs the value of preventing this due to tech debt, especially since we should know what version we want.

[Cedric / ViaDézo1er (viadezo1er)]

Maybe remove the .upper() line 294 to match the behavior when writing to a file (when the flag --github-output is passed)?

[Abhijeet Prasad (AbhiPrasad)]

Made the change to handle prerelease NOT-A-VALID-REF in b3c85e8. also addressed the .upper change.

--run-number n is manually set by the user, so it's a bit error prone, we might decrement or skip version number.

I agree! But we can address this in a follow up.

[Andrew Kent (realark)]

nit: pin to specific version?

[Abhijeet Prasad (AbhiPrasad)]

I'll do this as a follow up! We gotta fix that in all of our CI workflows.