Automated release workflow

[trask]

Hey all!

We've spent a lot of time lately improving our release workflow in the OTel Java repos, and I'd like to see if our toil and pain can be of any benefit to other repos (starting with python of course!).

I also think there's some benefit of shared cross-SIG knowledge going forward if we follow somewhat similar workflow practices.

I've tried to document things here: https://github.com/trask/repository-template/blob/main/template-docs/release-automation.md

Some highlights in this PR:

• Uses -dev version suffix on main (@lzchen mentioned you were thinking about doing this anyways)
• The release workflow autogenerates the release notes from the change log and publishes the github release
• Uses the bot workaround discussed in Add github-actions[bot] to EasyCLA allowlist community#809 (comment) (maybe we should consider creating a shared otel bot that all repos could use?)
• The branch names are based on the minor release (e.g. release/v1.12.x-0.31bx), and patch releases are made out of those same branches. Tags are still applied to each individual release.

New complications in this repo that we hadn't faced in the Java repos:

• Separate versions for stable/unstable components (this wasn't a big deal, just a bit more workflow code to handle/increment them both).
• I tried adding the Skip Changelog label to the generated pull requests that target main, but that requires giving the bot triage rights to the repo, so instead suppressed the changelog workflow when github.actor is the bot.

I'd love to stop by your SIG meeting, but it's always at the same time as the Java SIG 😢. Maybe next week I can sneak away and jump to your meeting for a bit.

Please throw your questions this way though, I'd love to better understand where we can align more, and where things will naturally diverge based on SIG needs/preferences.

[srikanthccv]

This is nice

[trask]

I should have mentioned, I tested all of these workflows on my python repo fork, though there may still be a hiccup or two on the first try here. I'd be happy to coordinate and be online with you during the first release using these new workflows if you are interested.

[srikanthccv]

Sorry I haven't gotten a time to review this in detail but there are many things I like about this. Team has been focused on getting the rc for metrics work for the past few weeks. So it might take sometime before we review and get it merged.

[trask]

@lzchen thanks for all the comments! I have made several updates and I think replied to all of your comments, happy to make further updates

[srikanthccv]

@trask will it be possible for you to attend tomorrow python SIG meeting and present it to all?

[trask]

@trask will it be possible for you to attend tomorrow python SIG meeting and present it to all?

yes, I'll plan on it, would it work to join at 9:30am Pacific Time?

[srikanthccv]

That should work

[lzchen]

@trask

Will be approving after the rc case has been confirmed to work.

[trask]

I updated the workflow to work with "pre-release" versions, e.g. "1.13.0rc", and tested making a "pre-release" in https://github.com/trask/repository-template/releases/tag/v1.1.0rc.

I'll re-test the full workflow in my opentelemetry-python fork one last time once everything is approved, but first could use some help resolving the build error below:

ERROR: Cannot install opentelemetry-instrumentation-requests==0.31b0, opentelemetry-sdk==1.13.0.dev0 and opentelemetry-semantic-conventions 0.32b0.dev0 (from /home/runner/work/opentelemetry-python/opentelemetry-python/opentelemetry-semantic-conventions) because these package versions have conflicting dependencies.

The conflict is caused by:
The user requested opentelemetry-semantic-conventions 0.32b0.dev0 (from /home/runner/work/opentelemetry-python/opentelemetry-python/opentelemetry-semantic-conventions)
opentelemetry-sdk 1.13.0.dev0 depends on opentelemetry-semantic-conventions==0.32b0-dev
opentelemetry-instrumentation-requests 0.31b0 depends on opentelemetry-semantic-conventions==0.31b0

To fix this you could try to:

1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

[trask]

Rebased and re-tested the release process (both minor and patch) in my fork.

I realized that the backport automation (for patches) will fail currently most of the time due to change log conflicts. I think I can make the backport automation smarter and handle that, but I don't think it's necessarily required for landing this PR, as backports for patch releases can still be done manually.

[srikanthccv]

Thanks, We will need to do this for contrib as well, not necessarily immediately.

[srikanthccv]

Ah I see the failed jobs are because the contrib versions are not .dev and fail to work. I think it's going to some effort to create same for contrib. We can mark not required for the time being but I would like to see that addressed soon as well. What do you think @lzchen

[lzchen]

@srikanthccv
When you say marked not required, do you mean marking the contrib tests as not required for merging? I am fine with that for now. As for how to fix the builds in the near future, it should simply be marking the contrib versions with dev right?

[srikanthccv]

When you say marked not required, do you mean marking the contrib tests as not required for merging? I am fine with that for now

I was talking about the trace-context job, the contrib-build tests are already not marked required.

As for how to fix the builds in the near future, it should simply be marking the contrib versions with dev right?

Yes.