Migrate ocb binary release to opentelemetry-collector-releases (#10710)

After discussion with the collector SIG call this week, July
31st, I have made small tweaks to the artifact release that will not
require an "extra step" of pushing tags. If these changes are accepted,
the distributions will be released under tag "vX.XXX.X" and the ocb
binaries will be released under "cmd/builder/vX.XXX.X" but both under
this repo, opentelemetry-collector-releases. The workflow
`builder-release.yaml` in releases repo will push the additional tags
necessary for the builder release.

Refactoring the release process as mentioned in past issues/PRs. ocb
binary is currently released in a separate release tag under this
repository, which makes it harder to find and inconsistent with the rest
of the binaries and images releasing in the
opentelemetry-collector-releases repository.

Releasing the ocb binaries in opentelemetry-collector-releases makes
this process more standardized and also opens the opportunity to release
more tools alongside ocb binary down the road, like corresponding docker
images (as discussed in #5712).

#### Link to tracking issue
Fixes #10662
Mentioned in [releases issue #
295](open-telemetry/opentelemetry-collector-releases#295)
[Corresponding PR in
opentelemetry-collector-releases](open-telemetry/opentelemetry-collector-releases#608)

#### Testing
Sample binary release in [forked
jackgopack4/opentelemetry-collector-releases
repo](https://github.com/jackgopack4/opentelemetry-collector-releases/releases/tag/cmd%2Fbuilder%2Fv0.106.1)

#### Documentation
Updated corresponding documentation to reflect new release process

---------

Co-authored-by: Pablo Baeyens <[email protected]>

Author: jackgopack4

.chloggen/ocb-migration.yaml

@@ -0,0 +1,25 @@
+# Use this changelog template to create an entry for release notes.
+
+# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix'
+change_type: enhancement
+
+# The name of the component, or a single word describing the area of concern, (e.g. otlpreceiver)
+component: ocb
+
+# A brief description of the change.  Surround your text with quotes ("") if it needs to start with a backtick (`).
+note: migrate build and release of ocb binaries to opentelemetry-collector-releases repository
+
+# One or more tracking issues or pull requests related to the change
+issues: [10710]
+
+# (Optional) One or more lines of additional information to render under the primary note.
+# These lines will be padded with 2 spaces and then inserted directly into the document.
+# Use pipe (|) for multiline entries.
+subtext: ocb binaries will now be released under open-telemetry/opentelemetry-collector-releases tagged as "cmd/builder/vX.XXX.X"
+
+# Optional: The change log or logs in which this entry should be included.
+# e.g. '[user]' or '[user, api]'
+# Include 'user' if the change is relevant to end users.
+# Include 'api' if there is a change to a library API.
+# Default: '[user]'
+change_logs: [user]

.github/workflows/check-goreleaser.yaml

@@ -1,9 +1,9 @@
-name: Builder - Release
+name: Source Code - Release
 
 on:
   push:
     tags:
-      - 'v*'
+      - "v*"
 
 jobs:
   goreleaser:
@@ -13,19 +13,6 @@ jobs:
         uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
         with:
           fetch-depth: 0
-      - name: Setup Go
-        uses: actions/setup-go@0a12ed9d6a96ab950c8f026ed9f722fe0da7ef32 # v5.0.2
-        with:
-          go-version: ~1.21.5
-      - name: Run GoReleaser
-        uses: goreleaser/goreleaser-action@286f3b13b1b49da4ac219696163fb8c1c93e1200 # v6.0.0
-        with:
-          distribution: goreleaser-pro
-          version: latest
-          args: release --clean -f cmd/builder/.goreleaser.yml
-        env:
-          GORELEASER_KEY: ${{ secrets.GORELEASER_KEY }}
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       - name: Create Github Release
         run: |
           gh release create ${{ github.ref_name }} -t ${{ github.ref_name }} -n "### Images and binaries here: https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/${{ github.ref_name }}"

.github/workflows/builder-release.yaml renamed to .github/workflows/sourcecode-release.yaml

@@ -46,9 +46,7 @@ It is possible that a core approver isn't a contrib approver. In that case, the
 
    If you set your remote using `https` you need to include `REMOTE=https://github.com/open-telemetry/opentelemetry-collector.git` in each command. Wait for the new tag build to pass successfully.
 
-6. The release script for the collector builder should create a new GitHub release for the builder. This is a separate release from the core, but we might join them in the future if it makes sense.
-
-7. A new `v0.85.0` release should be automatically created on Github by now. Edit it and use the contents from the CHANGELOG.md and CHANGELOG-API.md as the release's description.
+6. A new `v0.85.0` source code release should be automatically created on Github by now. Edit it and use the contents from the CHANGELOG.md and CHANGELOG-API.md as the release's description.
 
 ## Releasing opentelemetry-collector-contrib
 
@@ -74,10 +72,9 @@ It is possible that a core approver isn't a contrib approver. In that case, the
 5. A new `v0.85.0` release should be automatically created on Github by now. Edit it and use the contents from the CHANGELOG.md as the release's description.
 
 ## Producing the artifacts
-
 The last step of the release process creates artifacts for the new version of the collector and publishes images to Dockerhub. The steps in this portion of the release are done in the [opentelemetry-collector-releases](https://github.com/open-telemetry/opentelemetry-collector-releases) repo.
 
-1. Update the `./distribution/**/manifest.yaml` files to include the new release version.
+1. Update the `./distributions/**/manifest.yaml` files to include the new release version.
 
 2. Update the builder version in `OTELCOL_BUILDER_VERSION` to the new release in the `Makefile`. While this might not be strictly necessary for every release, this is a good practice.
 
@@ -86,12 +83,14 @@ The last step of the release process creates artifacts for the new version of th
 
 4. Check out the commit created by merging the PR and tag with the new release version by running the `make push-tags TAG=v0.85.0` command. If you set your remote using `https` you need to include `REMOTE=https://github.com/open-telemetry/opentelemetry-collector-releases.git` in each command. Wait for the new tag build to pass successfully.
 
-5. Ensure the "Release Core", "Release Contrib" and "Release k8s" actions pass, this will
+5. Ensure the "Release Core", "Release Contrib", "Release k8s", and "Builder - Release" actions pass, this will
 
     1. push new container images to `https://hub.docker.com/repository/docker/otel/opentelemetry-collector`, `https://hub.docker.com/repository/docker/otel/opentelemetry-collector-contrib` and `https://hub.docker.com/repository/docker/otel/opentelemetry-collector-k8s`
 
     2. create a Github release for the tag and push all the build artifacts to the Github release. See [example](https://github.com/open-telemetry/opentelemetry-collector-releases/actions/workflows/release-core.yaml).
 
+    3. build and release ocb binaries under a separate tagged Github release, e.g. `cmd/builder/v0.85.0`
+
 ## Troubleshooting
 
 1. `unknown revision internal/coreinternal/v0.85.0` -- This is typically an indication that there's a dependency on a new module. You can fix it by adding a new `replaces` entry to the `go.mod` for the affected module.