Proposal: Add GitHub Actions release and nightly CD workflows

[AzfaarQureshi]

trafficstars

Proposal: Add GitHub Actions release and nightly CD workflows

As a follow-up to issue #880 and PR #1382 I would like to start a discussion on how we could add CD jobs to our existing GitHub Actions workflow. My proposal is to add two new jobs: release and nightly.

The current process is manual on-purpose as the release requires some human verification. However, it would be great if the SDK releases can strike a balance with automation by having patch releases (v1.2.x) be completely automated. Major and minor releases (v X.x.0) would still be triggered manually by pushing a new tag to master but the CD job can handle the rest.

The benefit of having both triggers is that we can establish a regular release cadence through automation while still providing a manual method for maintainers to create emergency or major version releases. Regular releases help build trust and confidence in the project by ensuring users have regular access to the latest stable changes.

Release Workflow

Trigger	What the workflow does
1. When a new tag is pushed to master 2. Automatically every 2 weeks	1. Run CI jobs 2. Create a release with body from CHANGELOG.md 3. Run ./verify_examples.sh after release is made 4. Send dispatch event to contrib repo to start a release there

The release workflow will be triggered in two ways: manually by pushing a new tag to master or automatically based on a schedule (proposed schedule is every 2 weeks). If a tag is pushed manually then the workflow will use that to create a release. However, if the job is triggered through the schedule (i.e no tag is provided) then the workflow will create a tag itself by automatically incrementing the patch version (v.1.2.x) of the current release.

Regardless of trigger method, the workflow will always:

1. Run the CI jobs to ensure repo is stable
2. Update the contents of CHANGELOG.md for the release
   • move everything from ## [Unreleased] under ## [NEWTAG]
   • update [Unreleased]: https://github.com/open-telemetry/opentelemetry-go/compare/NEWTAG...HEAD near the bottom of the file
   • add [NEWTAG]: https://github.com/open-telemetry/opentelemetry-go/releases/tag/NEWTAG near the bottom of the file
3. Create a GitHub release with the body contents from CHANGELOG.md
4. After a release is created, run ./verify_examples.sh to ensure examples can be built outside of the repository
5. Send a workflow dispatch event to contrib to kickoff the release job there

There would be a matching release job in the Contrib repo.

Nightly Workflow

Trigger	What the workfklow does
Daily at 23:59 PST	runs the release job daily with the :nightly tag

The nightly workflow will just call the release workflow daily. Releases will be tagged with :nightly to differentiate this from a normal release. A nightly release CD workflow would be very useful for developers on the project to build and test with a current snapshot. This nightly build would also provide a pulse on whether the SDK builds are passing, and it would also provide easier access to an up-to-date build for those working closely with opentelemetry-go in their own projects.

cc - @alolita, @MrAlias

[dashpole]

Small suggestion: use "canary" instead of "nightly" to give us more flexibility on when we want to run the all-the-time build.

I'm not a maintainer, but when i've maintained projects in the past there are often times when I don't want a release cut--either because of a regression, because I want to wait for it to include a particular fix of high importance, or because e2e tests (not part of presubmit) are not passing. If it were me, i'd lean toward manually tagging all releases.

I'm also quite interested in this myself, and am happy to help out.

[Aneurysm9]

I'm definitely for automating as much of the release process as possible, though without programmatic means to ensure semver-compliant version increments I don't think that I would be in support of automating the decision to release. It seems to me that it would be unsafe to assume that all changes within any given two-week window were patch-level changes or that manual releases happened after every minor- or major-level change.

Until we have the stability of a 1.x release I don't think that it is feasible to automatically trigger a release of the contrib repo as we typically have significant work to do there updating instrumentation impacted by breaking changes. If contrib repo releases become a non-event post-1.0 then I think revisiting the idea of automatically triggering a release there after a release here would be good.

I'm not sure I see the value of the nightly/canary workflow. I do think that canary is probably the better term, but I also think that our requirement that all PRs pass CI tests before merging and running the tests again anytime anything hits the trunk is sufficient to ensure that something always exists that can be imported and will compile if developers want the bleeding edge.