[repo] Automate release process

[CodeBlanch]

Changes

• Adds a prepare-release.yml workflow which has this flow (for some selected component + version):
  • Open a PR to update CHANGELOGs and public api files (stable releases only).
  • Once that PR is merged you can reply /CreateReleaseTag on that PR and packages will be created and uploaded to NuGet and a release created. For stable releases a follow-up PR is opened to update PackageValidationBaselineVersion for the released projects.

Here's a test run: CodeBlanch#32

If someone was so inclined, it should be possible to release from a phone now 😄

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.96%. Comparing base (71655ce) to head (d3331bf).
Report is 276 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1841      +/-   ##
==========================================
+ Coverage   73.91%   73.96%   +0.05%     
==========================================
  Files         267      294      +27     
  Lines        9615    10825    +1210     
==========================================
+ Hits         7107     8007     +900     
- Misses       2508     2818     +310     

Flag	Coverage Δ
unittests-Exporter.Geneva	63.81% <ø> (?)
unittests-Exporter.InfluxDB	94.65% <ø> (?)
unittests-Exporter.Instana	68.22% <ø> (?)
unittests-Exporter.OneCollector	89.46% <ø> (?)
unittests-Exporter.Stackdriver	75.73% <ø> (?)
unittests-Extensions	79.33% <ø> (?)
unittests-Extensions.AWS	77.24% <ø> (?)
unittests-Extensions.Enrichment	100.00% <ø> (?)
unittests-Instrumentation.AWS	87.37% <ø> (?)
unittests-Instrumentation.AWSLambda	87.96% <ø> (?)
unittests-Instrumentation.AspNet	74.55% <ø> (?)
unittests-Instrumentation.AspNetCore	85.27% <ø> (?)
unittests-Instrumentation.ElasticsearchClient	79.87% <ø> (?)
unittests-Instrumentation.EntityFrameworkCore	55.49% <ø> (?)
unittests-Instrumentation.EventCounters	76.36% <ø> (?)
unittests-Instrumentation.GrpcNetClient	79.61% <ø> (?)
unittests-Instrumentation.Hangfire	93.58% <ø> (?)
unittests-Instrumentation.Http	81.08% <ø> (?)
unittests-Instrumentation.Owin	83.43% <ø> (?)
unittests-Instrumentation.Process	100.00% <ø> (?)
unittests-Instrumentation.Quartz	78.94% <ø> (?)
unittests-Instrumentation.Runtime	100.00% <ø> (?)
unittests-Instrumentation.SqlClient	90.90% <ø> (?)
unittests-Instrumentation.StackExchangeRedis	71.00% <ø> (?)
unittests-Instrumentation.Wcf	48.91% <ø> (?)
unittests-PersistentStorage	65.44% <ø> (?)
unittests-ResourceDetectors.AWS	76.83% <ø> (?)
unittests-ResourceDetectors.Container	75.00% <ø> (?)
unittests-Resources.Azure	78.35% <ø> (?)
unittests-Resources.Gcp	72.54% <ø> (?)
unittests-Resources.Host	51.16% <ø> (?)
unittests-Resources.Process	81.81% <ø> (?)
unittests-Resources.ProcessRuntime	72.91% <ø> (?)
unittests-Sampler.AWS	87.97% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 290 files with indirect coverage changes

[CodeBlanch]

Just FYI I went with OpenTelemetry.Resources for all of these here. Seems like we'll be there soon. For ones that aren't updated, they can still be released doing everything manually the old way. Or we could just use the existing names and fix them up as we go. I thought this might save a bit of work.

[Kielek]

I like overall idea of releasing through GitHub pages.

Based on what I see, the whole process has to be either fully handled by new pipeline or fully in the old way.

The new way is IMO great for packages owned and released by maintainers. It works great.
I see two potential things to improve:

1. Allow created end-users requests as described in https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/f1ec716d54eaa26bb15b79fc3f3dc2d749f19c98/CONTRIBUTING.md#how-to-request-for-release-of-package and then follow the process by the automated cases. It will allow us to use automated process for packages used by non-maintainers.
2. Bulk releases as in Releases with OTel 1.8.0 #1636 - now, we can do it only one by one. I think that the manual way will be faster than here.

[Kielek]

LGTM as the first step. Additional comments already posted.

[Kielek]

This is kid of misleading. This packages are released always together.

Similar thing for OpenTelemetry.PersistentStorage.*

[CodeBlanch]

Agree. Really this list should be the tag prefixes not components. I decided to go with components though because a) in most cases that is what users will be looking for (probably?) and b) it makes it easy to keep this list in sync with the other places it is mirrored (issue templates). I was hoping there was a way in yaml to pull in a list of items from another file so we could have a single source of truth for the set of known components but it doesn't seem possible 😢

How it works is you pick a component. The workflow will look for a csproj for that component. Then it will find the MinVerTagPrefix for that project. The release is then performed for that MinVerTagPrefix. So when it comes to OpenTelemetry.Instrumentation.AspNet* and OpenTelemetry.PersistentStorage* you have to kick off the job for one of the components in the set (doesn't matter which) and the job will release both. It is a bit odd, but I think the benefits outweigh the quirk(s)?

Let me respond to some of the other comments on here...

Based on what I see, the whole process has to be either fully handled by new pipeline or fully in the old way.

Not true! When you kick off the job a PR will be opened to update CHANGELOGs and public api files (for stable releases). Someone has to merge that. Then the bot will ask you if you want it to create the tag. If you choose to not have the bot create the tag, you can do everything the manual way. Probably easier to let the bot do it, but it isn't forced 😄

Allow created end-users requests as described in

Agree with this. To kick off this new job you need to be a collaborator in the repo (write access). This will help maintainers but it won't be widely useful. What I am thinking is add an issue template for "Request release" end users may use to request a release be done. I'm hoping the flow will be users select a component, and then the bot can look for code owners for the selected component to approve before kicking off the job. That would give us a nice flow/mechanism. Going to look at that as a follow-up.

Bulk releases

I think this is already covered by: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/actions/workflows/core-version-update.yml

Maintainers can kick that workflow off anytime a core release happens and it will generate the PR to bump all the components. My goal is to have the main repo automatically call this but that isn't in place yet.