chore(ci): introduce daily pre-releases

[heitorlessa]

Issue number: #4506

Summary

Test CI: https://github.com/heitorlessa/aws-lambda-powertools-python/actions/runs/9547633628
PR sample: https://github.com/heitorlessa/aws-lambda-powertools-python/pull/437/files

This PR introduces a new workflow to release alpha releases (a.k.a pre-releases) on a daily basis. This is due to last release having an undetected regression that a canary and tests with optional dependencies could've prevented.

With pre-releases, we have the following benefits:

1. Faster bugfix delivery for customers not wanting to wait the next release cycle. (note: bugs that affect most customers are delivered same day, that doesn't change it)
2. Test our release pipeline daily (except Layers)
3. Allows a future complex canary to test daily changes for timely feedback

Changes

Please provide a summary of what's being changed

• Verify RELEASE_VERSION is a pre-release version to avoid accidental releases / pollution
• Keep same steps and comments as much as possible from prod release
• Create manual dispatch trigger
• Create on schedule trigger
• Test a release manually
• Include provenance as part of release bump PR and src code
• Adjust build-changelog to run after pre-release so we can trace it (workflow+docs)
• Skip workflow if running on forks
• Include provenance in PR
• Create new trusted environment called pre-release to allow PyPi deployment
• Create GitHub Actions environment named pre-release
• Update install docs with tab on pre-releases to make it visible
• Adjust schedule to weekdays
• Update MAINTAINERS.md covering daily pre-release

Requirements matching

• Confirm whether .alpha over poetry default .a is a deal breaker (nope)
• Release every weekday early morning (on-call coverage, no impact to release day)
• Do not touch CHANGELOG (avoid spam, doesn't affect stable release on what's in it)
• PyPi only; do not release a new Lambda Layer (no alias yet, it'd impact versioning)
• Create PR to update pyproject.toml and shared/version.py (ensure deterministic for next release)
• Ensure it doesn't create a new release notes (avoid spam, provenance signing etc)
• Always autoincrement pre-release version (keep it simple over substantial checking for changes, dep/runtime
  devs etc)
• Run full quality check and test suite
• Do not release docs for each pre-release (develop covers it, avoid dropdown UX issue)
• Allow manual trigger a.k.a dispatch
• Release to PyPi prod, not PyPi test (test pypi maintenance and supply chain differences)
• Do not touch pending-release issues (no post-release prod tasks)

User experience

Please share what the user experience looks like before and after this change

Checklist

If your change doesn't seem to apply, please leave them unchecked.

• Meet tenets criteria
• I have performed a self-review of this change
• Changes have been tested
• Changes are documented
• PR title follows conventional commit semantics

Is this a breaking change?

RFC issue number:

Checklist:

• Migration process documented
• Implement warnings (if it can live side by side)

Acknowledgment

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[heitorlessa]

one last change (tomorrow) but ready to review @leandrodamascena. I had to change the Install section to make this fit.

[leandrodamascena]

Hello @heitorlessa! We're making incredible progress in having pre-releases and allowing customers to test things before they go to production. Thanks for working on this, I couldn't do better than you did here.

I left some small changes and questions!

[leandrodamascena]

AMAZING WORK @heitorlessa! ❤️

APPROVED!!!!