From d33a79a0556566add694785d8db121b17c6558d8 Mon Sep 17 00:00:00 2001 From: jackgopack4 Date: Thu, 1 Aug 2024 16:23:05 -0400 Subject: [PATCH 1/3] Migrate ocb binary release to opentelemetry-collector-releases #10710 --- .chloggen/ocb-migration.yaml | 25 +++++++ .github/workflows/check-goreleaser.yaml | 32 --------- ...r-release.yaml => sourcecode-release.yaml} | 17 +---- cmd/builder/.goreleaser.yml | 39 ----------- docs/release.md | 69 +++++++++---------- 5 files changed, 61 insertions(+), 121 deletions(-) create mode 100644 .chloggen/ocb-migration.yaml delete mode 100644 .github/workflows/check-goreleaser.yaml rename .github/workflows/{builder-release.yaml => sourcecode-release.yaml} (72%) delete mode 100644 cmd/builder/.goreleaser.yml diff --git a/.chloggen/ocb-migration.yaml b/.chloggen/ocb-migration.yaml new file mode 100644 index 00000000000..1c59d893b3a --- /dev/null +++ b/.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 will 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] diff --git a/.github/workflows/check-goreleaser.yaml b/.github/workflows/check-goreleaser.yaml deleted file mode 100644 index 875b4b17f7c..00000000000 --- a/.github/workflows/check-goreleaser.yaml +++ /dev/null @@ -1,32 +0,0 @@ -name: Check GoReleaser Config -on: - push: - branches: [main] - tags: - - "v[0-9]+.[0-9]+.[0-9]+*" - pull_request: - -permissions: - contents: read - -jobs: - check: - runs-on: ubuntu-latest - steps: - - name: Checkout Repo - 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: Check GoReleaser - uses: goreleaser/goreleaser-action@286f3b13b1b49da4ac219696163fb8c1c93e1200 # v6.0.0 - with: - distribution: goreleaser-pro - version: latest - args: check --verbose cmd/builder/.goreleaser.yml - env: - GORELEASER_KEY: ${{ secrets.GORELEASER_KEY }} - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/builder-release.yaml b/.github/workflows/sourcecode-release.yaml similarity index 72% rename from .github/workflows/builder-release.yaml rename to .github/workflows/sourcecode-release.yaml index b6ae4795adb..7e767539fc9 100644 --- a/.github/workflows/builder-release.yaml +++ b/.github/workflows/sourcecode-release.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 }}" diff --git a/cmd/builder/.goreleaser.yml b/cmd/builder/.goreleaser.yml deleted file mode 100644 index a964ac6c6ee..00000000000 --- a/cmd/builder/.goreleaser.yml +++ /dev/null @@ -1,39 +0,0 @@ -before: - hooks: - - go mod download -monorepo: - tag_prefix: cmd/builder/ - dir: cmd/builder -builds: - - flags: - - -trimpath - ldflags: - - -s -w -X go.opentelemetry.io/collector/cmd/builder/internal.version={{.Version}} -X go.opentelemetry.io/collector/cmd/builder/internal.date={{.Date}} - env: - - CGO_ENABLED=0 - goos: - - linux - - windows - - darwin - goarch: - - amd64 - - arm64 - - ppc64le - ignore: - - goos: windows - goarch: arm64 - binary: ocb -release: - github: - owner: open-telemetry - name: opentelemetry-collector - header: | - ### Images and binaries here: https://github.com/open-telemetry/opentelemetry-collector-releases/releases/tag/{{ .Tag }} -archives: - - format: binary -checksum: - name_template: "checksums.txt" -snapshot: - name_template: "{{ .Tag }}-next" -changelog: - disable: true diff --git a/docs/release.md b/docs/release.md index 38dad9e75cb..e71893a2f44 100644 --- a/docs/release.md +++ b/docs/release.md @@ -28,27 +28,25 @@ It is possible that a core approver isn't a contrib approver. In that case, the 1. Update Contrib to use the latest in development version of Core by running `make update-otel` in Contrib root directory. This is to ensure that the latest core does not break contrib in any way. If it results in any changes, submit a PR to Contrib. - 🛑 **Do not move forward until this PR is merged.** -2. Determine the version number that will be assigned to the release. Usually, we increment the minor version number and set the patch number to 0. In this document, we are using `v0.85.0` as the version to be released, following `v0.84.0`. +1. Determine the version number that will be assigned to the release. Usually, we increment the minor version number and set the patch number to 0. In this document, we are using `v0.85.0` as the version to be released, following `v0.84.0`. Check if stable modules have any changes since the last release by running `make check-changes PREVIOUS_VERSION=v1.0.0 MODSET=stable`. If there are no changes, there is no need to release new version for stable modules. If there are changes found but .chloggen directory doesn't have any corresponding entries, add missing changelog entries. If the changes are insignificant, consider not releasing a new version for stable modules. -3. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector/actions/workflows/prepare-release.yml). This action will create an issue to track the progress of the release and a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Core should be halted**. +1. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector/actions/workflows/prepare-release.yml). This action will create an issue to track the progress of the release and a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Core should be halted**. - When prompted, enter the version numbers determined in Step 2, but do not include a leading `v`. - If not intending to release stable modules, do not specify a version for `Release candidate version stable`. - If the PR needs updated in any way you can make the changes in a fork and PR those changes into the `prepare-release-prs/x` branch. You do not need to wait for the CI to pass in this prep-to-prep PR. - 🛑 **Do not move forward until this PR is merged.** 🛑 -4. Check out the commit created by merging the PR created by `Automation - Prepare Release` (e.g. `prepare-release-prs/0.85.0`) and create a branch named `release/` (e.g. `release/v0.85.x`). Push the new branch to `open-telemetry/opentelemetry-collector`. +1. Check out the commit created by merging the PR created by `Automation - Prepare Release` (e.g. `prepare-release-prs/0.85.0`) and create a branch named `release/` (e.g. `release/v0.85.x`). Push the new branch to `open-telemetry/opentelemetry-collector`. -5. Make sure you are on `release/`. Tag the module groups with the new release version by running: +1. Make sure you are on `release/`. Tag the module groups with the new release version by running: - `make push-tags MODSET=beta` for beta modules group, - `make push-tags MODSET=stable` for stable modules group, only if there were changes since the last release. 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. +1. 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 @@ -63,42 +61,43 @@ It is possible that a core approver isn't a contrib approver. In that case, the - Open a PR - 🛑 **Do not move forward until this PR is merged.** 🛑 -2. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/workflows/prepare-release.yml). When prompted, enter the version numbers determined in Step 1, but do not include a leading `v`. This action will create a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Contrib should be halted**. +1. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/workflows/prepare-release.yml). When prompted, enter the version numbers determined in Step 1, but do not include a leading `v`. This action will create a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Contrib should be halted**. - If the PR needs updated in any way you can make the changes in a fork and PR those changes into the `prepare-release-prs/x` branch. You do not need to wait for the CI to pass in this prep-to-prep PR. - 🛑 **Do not move forward until this PR is merged.** 🛑 -3. Check out the commit created by merging the PR created by `Automation - Prepare Release` (e.g. `prepare-release-prs/0.85.0`) and create a branch named `release/` (e.g. `release/v0.85.x`). Push the new branch to `open-telemetry/opentelemetry-collector-contrib`. +1. Check out the commit created by merging the PR created by `Automation - Prepare Release` (e.g. `prepare-release-prs/0.85.0`) and create a branch named `release/` (e.g. `release/v0.85.x`). Push the new branch to `open-telemetry/opentelemetry-collector-contrib`. -4. Make sure you are on `release/`. Tag all the module groups (`contrib-base`) with the new release version by running the `make push-tags MODSET=contrib-base` command. If you set your remote using `https` you need to include `REMOTE=https://github.com/open-telemetry/opentelemetry-collector-contrib.git` in each command. Wait for the new tag build to pass successfully. +1. Make sure you are on `release/`. Tag all the module groups (`contrib-base`) with the new release version by running the `make push-tags MODSET=contrib-base` command. If you set your remote using `https` you need to include `REMOTE=https://github.com/open-telemetry/opentelemetry-collector-contrib.git` in each command. Wait for the new tag build to pass successfully. -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. +1. 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. +1. 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. -3. Create a pull request with the change and ensure the build completes successfully. See [example](https://github.com/open-telemetry/opentelemetry-collector-releases/pull/71). +1. Create a pull request with the change and ensure the build completes successfully. See [example](https://github.com/open-telemetry/opentelemetry-collector-releases/pull/71). - 🛑 **Do not move forward until this PR is merged.** 🛑 -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. +1. 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 +1. 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). + 1. 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). + + 1. 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. -2. `commitChangesToNewBranch failed: invalid merge` -- This is a [known issue](https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/47) with our release tooling. The current workaround is to clone a fresh copy of the repository and try again. Note that you may need to set up a `fork` remote pointing to your own fork for the release tooling to work properly. -3. `could not run Go Mod Tidy: go mod tidy failed` when running `multimod` -- This is a [known issue](https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/46) with our release tooling. The current workaround is to run `make gotidy` manually after the multimod tool fails and commit the result. -4. `Incorrect version "X" of "go.opentelemetry.io/collector/component" is included in "X"` in CI after `make update-otel` -- It could be because the make target was run too soon after updating Core and the goproxy hasn't updated yet. Try running `export GOPROXY=direct` and then `make update-otel`. -5. `error: failed to push some refs to 'https://github.com/open-telemetry/opentelemetry-collector-contrib.git'` during `make push-tags` -- If you encounter this error the `make push-tags` target will terminate without pushing all the tags. Using the output of the `make push-tags` target, save all the un-pushed the tags in `tags.txt` and then use this make target to complete the push: +1. `commitChangesToNewBranch failed: invalid merge` -- This is a [known issue](https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/47) with our release tooling. The current workaround is to clone a fresh copy of the repository and try again. Note that you may need to set up a `fork` remote pointing to your own fork for the release tooling to work properly. +1. `could not run Go Mod Tidy: go mod tidy failed` when running `multimod` -- This is a [known issue](https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/46) with our release tooling. The current workaround is to run `make gotidy` manually after the multimod tool fails and commit the result. +1. `Incorrect version "X" of "go.opentelemetry.io/collector/component" is included in "X"` in CI after `make update-otel` -- It could be because the make target was run too soon after updating Core and the goproxy hasn't updated yet. Try running `export GOPROXY=direct` and then `make update-otel`. +1. `error: failed to push some refs to 'https://github.com/open-telemetry/opentelemetry-collector-contrib.git'` during `make push-tags` -- If you encounter this error the `make push-tags` target will terminate without pushing all the tags. Using the output of the `make push-tags` target, save all the un-pushed the tags in `tags.txt` and then use this make target to complete the push: ```bash .PHONY: temp-push-tags @@ -120,10 +119,10 @@ When considering making a bugfix release on the `v0.N.x` release cycle, the bug 1. The bug has no workaround or the workaround is significantly harder to put in place than updating the version. Examples of simple workarounds are: - Reverting a feature gate. - Changing the configuration to an easy to find value. -2. The bug happens in common setups. To gauge this, maintainers can consider the following: +1. The bug happens in common setups. To gauge this, maintainers can consider the following: - If the bug is specific to a certain platform, and if that platform is in [Tier 1](../docs/platform-support.md#tiered-platform-support-model). - The bug happens with the default configuration or with a commonly used one (e.g. has been reported by multiple people) -3. The bug is sufficiently severe. For example (non-exhaustive list): +1. The bug is sufficiently severe. For example (non-exhaustive list): - The bug makes the Collector crash reliably - The bug makes the Collector fail to start under an accepted configuration - The bug produces significant data loss @@ -138,18 +137,18 @@ The OpenTelemetry Collector maintainers will ultimately have the responsibility The following documents the procedure to release a bugfix 1. Create a pull request against the `release/` (e.g. `release/v0.90.x`) branch to apply the fix. -2. Make sure you are on `release/`. Prepare release commits with `prepare-release` make target, e.g. `make prepare-release PREVIOUS_VERSION=0.90.0 RELEASE_CANDIDATE=0.90.1 MODSET=beta`, and create a pull request against the `release/` branch. -3. Once those changes have been merged, create a pull request to the `main` branch from the `release/` branch. -4. If you see merge conflicts when creating the pull request, do the following: +1. Make sure you are on `release/`. Prepare release commits with `prepare-release` make target, e.g. `make prepare-release PREVIOUS_VERSION=0.90.0 RELEASE_CANDIDATE=0.90.1 MODSET=beta`, and create a pull request against the `release/` branch. +1. Once those changes have been merged, create a pull request to the `main` branch from the `release/` branch. +1. If you see merge conflicts when creating the pull request, do the following: 1. Create a new branch from `origin:main`. - 2. Merge the `release/` branch into the new branch. - 3. Resolve the conflicts. - 4. Create another pull request to the `main` branch from the new branch to replace the pull request from the `release/` branch. -5. Enable the **Merge pull request** setting in the repository's **Settings** tab. -6. Make sure you are on `release/`. Push the new release version tags for a target module set by running `make push-tags MODSET=`. Wait for the new tag build to pass successfully. -7. **IMPORTANT**: The pull request to bring the changes from the release branch *MUST* be merged using the **Merge pull request** method, and *NOT* squashed using “**Squash and merge**”. This is important as it allows us to ensure the commit SHA from the release branch is also on the main branch. **Not following this step will cause much go dependency sadness.** -8. If the pull request was created from the `release/` branch, it will be auto-deleted. Restore the release branch via GitHub. -9. Once the patch is released, disable the **Merge pull request** setting. + 1. Merge the `release/` branch into the new branch. + 1. Resolve the conflicts. + 1. Create another pull request to the `main` branch from the new branch to replace the pull request from the `release/` branch. +1. Enable the **Merge pull request** setting in the repository's **Settings** tab. +1. Make sure you are on `release/`. Push the new release version tags for a target module set by running `make push-tags MODSET=`. Wait for the new tag build to pass successfully. +1. **IMPORTANT**: The pull request to bring the changes from the release branch *MUST* be merged using the **Merge pull request** method, and *NOT* squashed using “**Squash and merge**”. This is important as it allows us to ensure the commit SHA from the release branch is also on the main branch. **Not following this step will cause much go dependency sadness.** +1. If the pull request was created from the `release/` branch, it will be auto-deleted. Restore the release branch via GitHub. +1. Once the patch is released, disable the **Merge pull request** setting. ## 1.0 release From 9338f3bd830a2212187bf136dd94986e031012ef Mon Sep 17 00:00:00 2001 From: jackgopack4 Date: Fri, 2 Aug 2024 10:32:47 -0400 Subject: [PATCH 2/3] revert numbering changes --- docs/release.md | 64 ++++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/docs/release.md b/docs/release.md index e71893a2f44..9057f06d1c1 100644 --- a/docs/release.md +++ b/docs/release.md @@ -28,25 +28,25 @@ It is possible that a core approver isn't a contrib approver. In that case, the 1. Update Contrib to use the latest in development version of Core by running `make update-otel` in Contrib root directory. This is to ensure that the latest core does not break contrib in any way. If it results in any changes, submit a PR to Contrib. - 🛑 **Do not move forward until this PR is merged.** -1. Determine the version number that will be assigned to the release. Usually, we increment the minor version number and set the patch number to 0. In this document, we are using `v0.85.0` as the version to be released, following `v0.84.0`. +2. Determine the version number that will be assigned to the release. Usually, we increment the minor version number and set the patch number to 0. In this document, we are using `v0.85.0` as the version to be released, following `v0.84.0`. Check if stable modules have any changes since the last release by running `make check-changes PREVIOUS_VERSION=v1.0.0 MODSET=stable`. If there are no changes, there is no need to release new version for stable modules. If there are changes found but .chloggen directory doesn't have any corresponding entries, add missing changelog entries. If the changes are insignificant, consider not releasing a new version for stable modules. -1. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector/actions/workflows/prepare-release.yml). This action will create an issue to track the progress of the release and a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Core should be halted**. +3. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector/actions/workflows/prepare-release.yml). This action will create an issue to track the progress of the release and a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Core should be halted**. - When prompted, enter the version numbers determined in Step 2, but do not include a leading `v`. - If not intending to release stable modules, do not specify a version for `Release candidate version stable`. - If the PR needs updated in any way you can make the changes in a fork and PR those changes into the `prepare-release-prs/x` branch. You do not need to wait for the CI to pass in this prep-to-prep PR. - 🛑 **Do not move forward until this PR is merged.** 🛑 -1. Check out the commit created by merging the PR created by `Automation - Prepare Release` (e.g. `prepare-release-prs/0.85.0`) and create a branch named `release/` (e.g. `release/v0.85.x`). Push the new branch to `open-telemetry/opentelemetry-collector`. +4. Check out the commit created by merging the PR created by `Automation - Prepare Release` (e.g. `prepare-release-prs/0.85.0`) and create a branch named `release/` (e.g. `release/v0.85.x`). Push the new branch to `open-telemetry/opentelemetry-collector`. -1. Make sure you are on `release/`. Tag the module groups with the new release version by running: +5. Make sure you are on `release/`. Tag the module groups with the new release version by running: - `make push-tags MODSET=beta` for beta modules group, - `make push-tags MODSET=stable` for stable modules group, only if there were changes since the last release. 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. -1. 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. +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 @@ -61,43 +61,43 @@ It is possible that a core approver isn't a contrib approver. In that case, the - Open a PR - 🛑 **Do not move forward until this PR is merged.** 🛑 -1. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/workflows/prepare-release.yml). When prompted, enter the version numbers determined in Step 1, but do not include a leading `v`. This action will create a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Contrib should be halted**. +2. Manually run the action [Automation - Prepare Release](https://github.com/open-telemetry/opentelemetry-collector-contrib/actions/workflows/prepare-release.yml). When prompted, enter the version numbers determined in Step 1, but do not include a leading `v`. This action will create a pull request to update the changelog and version numbers in the repo. **While this PR is open all merging in Contrib should be halted**. - If the PR needs updated in any way you can make the changes in a fork and PR those changes into the `prepare-release-prs/x` branch. You do not need to wait for the CI to pass in this prep-to-prep PR. - 🛑 **Do not move forward until this PR is merged.** 🛑 -1. Check out the commit created by merging the PR created by `Automation - Prepare Release` (e.g. `prepare-release-prs/0.85.0`) and create a branch named `release/` (e.g. `release/v0.85.x`). Push the new branch to `open-telemetry/opentelemetry-collector-contrib`. +3. Check out the commit created by merging the PR created by `Automation - Prepare Release` (e.g. `prepare-release-prs/0.85.0`) and create a branch named `release/` (e.g. `release/v0.85.x`). Push the new branch to `open-telemetry/opentelemetry-collector-contrib`. -1. Make sure you are on `release/`. Tag all the module groups (`contrib-base`) with the new release version by running the `make push-tags MODSET=contrib-base` command. If you set your remote using `https` you need to include `REMOTE=https://github.com/open-telemetry/opentelemetry-collector-contrib.git` in each command. Wait for the new tag build to pass successfully. +4. Make sure you are on `release/`. Tag all the module groups (`contrib-base`) with the new release version by running the `make push-tags MODSET=contrib-base` command. If you set your remote using `https` you need to include `REMOTE=https://github.com/open-telemetry/opentelemetry-collector-contrib.git` in each command. Wait for the new tag build to pass successfully. -1. 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. +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 `./distributions/**/manifest.yaml` files to include the new release version. -1. 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. +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. -1. Create a pull request with the change and ensure the build completes successfully. See [example](https://github.com/open-telemetry/opentelemetry-collector-releases/pull/71). +3. Create a pull request with the change and ensure the build completes successfully. See [example](https://github.com/open-telemetry/opentelemetry-collector-releases/pull/71). - 🛑 **Do not move forward until this PR is merged.** 🛑 -1. 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. +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. -1. Ensure the "Release Core", "Release Contrib", "Release k8s", and "Builder - Release" 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` - 1. 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). + 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). - 1. build and release ocb binaries under a separate tagged Github release, e.g. `cmd/builder/v0.85.0` + 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. -1. `commitChangesToNewBranch failed: invalid merge` -- This is a [known issue](https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/47) with our release tooling. The current workaround is to clone a fresh copy of the repository and try again. Note that you may need to set up a `fork` remote pointing to your own fork for the release tooling to work properly. -1. `could not run Go Mod Tidy: go mod tidy failed` when running `multimod` -- This is a [known issue](https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/46) with our release tooling. The current workaround is to run `make gotidy` manually after the multimod tool fails and commit the result. -1. `Incorrect version "X" of "go.opentelemetry.io/collector/component" is included in "X"` in CI after `make update-otel` -- It could be because the make target was run too soon after updating Core and the goproxy hasn't updated yet. Try running `export GOPROXY=direct` and then `make update-otel`. -1. `error: failed to push some refs to 'https://github.com/open-telemetry/opentelemetry-collector-contrib.git'` during `make push-tags` -- If you encounter this error the `make push-tags` target will terminate without pushing all the tags. Using the output of the `make push-tags` target, save all the un-pushed the tags in `tags.txt` and then use this make target to complete the push: +2. `commitChangesToNewBranch failed: invalid merge` -- This is a [known issue](https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/47) with our release tooling. The current workaround is to clone a fresh copy of the repository and try again. Note that you may need to set up a `fork` remote pointing to your own fork for the release tooling to work properly. +3. `could not run Go Mod Tidy: go mod tidy failed` when running `multimod` -- This is a [known issue](https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/46) with our release tooling. The current workaround is to run `make gotidy` manually after the multimod tool fails and commit the result. +4. `Incorrect version "X" of "go.opentelemetry.io/collector/component" is included in "X"` in CI after `make update-otel` -- It could be because the make target was run too soon after updating Core and the goproxy hasn't updated yet. Try running `export GOPROXY=direct` and then `make update-otel`. +5. `error: failed to push some refs to 'https://github.com/open-telemetry/opentelemetry-collector-contrib.git'` during `make push-tags` -- If you encounter this error the `make push-tags` target will terminate without pushing all the tags. Using the output of the `make push-tags` target, save all the un-pushed the tags in `tags.txt` and then use this make target to complete the push: ```bash .PHONY: temp-push-tags @@ -119,10 +119,10 @@ When considering making a bugfix release on the `v0.N.x` release cycle, the bug 1. The bug has no workaround or the workaround is significantly harder to put in place than updating the version. Examples of simple workarounds are: - Reverting a feature gate. - Changing the configuration to an easy to find value. -1. The bug happens in common setups. To gauge this, maintainers can consider the following: +2. The bug happens in common setups. To gauge this, maintainers can consider the following: - If the bug is specific to a certain platform, and if that platform is in [Tier 1](../docs/platform-support.md#tiered-platform-support-model). - The bug happens with the default configuration or with a commonly used one (e.g. has been reported by multiple people) -1. The bug is sufficiently severe. For example (non-exhaustive list): +3. The bug is sufficiently severe. For example (non-exhaustive list): - The bug makes the Collector crash reliably - The bug makes the Collector fail to start under an accepted configuration - The bug produces significant data loss @@ -137,18 +137,18 @@ The OpenTelemetry Collector maintainers will ultimately have the responsibility The following documents the procedure to release a bugfix 1. Create a pull request against the `release/` (e.g. `release/v0.90.x`) branch to apply the fix. -1. Make sure you are on `release/`. Prepare release commits with `prepare-release` make target, e.g. `make prepare-release PREVIOUS_VERSION=0.90.0 RELEASE_CANDIDATE=0.90.1 MODSET=beta`, and create a pull request against the `release/` branch. -1. Once those changes have been merged, create a pull request to the `main` branch from the `release/` branch. -1. If you see merge conflicts when creating the pull request, do the following: +2. Make sure you are on `release/`. Prepare release commits with `prepare-release` make target, e.g. `make prepare-release PREVIOUS_VERSION=0.90.0 RELEASE_CANDIDATE=0.90.1 MODSET=beta`, and create a pull request against the `release/` branch. +3. Once those changes have been merged, create a pull request to the `main` branch from the `release/` branch. +4. If you see merge conflicts when creating the pull request, do the following: 1. Create a new branch from `origin:main`. - 1. Merge the `release/` branch into the new branch. - 1. Resolve the conflicts. - 1. Create another pull request to the `main` branch from the new branch to replace the pull request from the `release/` branch. -1. Enable the **Merge pull request** setting in the repository's **Settings** tab. -1. Make sure you are on `release/`. Push the new release version tags for a target module set by running `make push-tags MODSET=`. Wait for the new tag build to pass successfully. -1. **IMPORTANT**: The pull request to bring the changes from the release branch *MUST* be merged using the **Merge pull request** method, and *NOT* squashed using “**Squash and merge**”. This is important as it allows us to ensure the commit SHA from the release branch is also on the main branch. **Not following this step will cause much go dependency sadness.** -1. If the pull request was created from the `release/` branch, it will be auto-deleted. Restore the release branch via GitHub. -1. Once the patch is released, disable the **Merge pull request** setting. + 2. Merge the `release/` branch into the new branch. + 3. Resolve the conflicts. + 4. Create another pull request to the `main` branch from the new branch to replace the pull request from the `release/` branch. +5. Enable the **Merge pull request** setting in the repository's **Settings** tab. +6. Make sure you are on `release/`. Push the new release version tags for a target module set by running `make push-tags MODSET=`. Wait for the new tag build to pass successfully. +7. **IMPORTANT**: The pull request to bring the changes from the release branch *MUST* be merged using the **Merge pull request** method, and *NOT* squashed using “**Squash and merge**”. This is important as it allows us to ensure the commit SHA from the release branch is also on the main branch. **Not following this step will cause much go dependency sadness.** +8. If the pull request was created from the `release/` branch, it will be auto-deleted. Restore the release branch via GitHub. +9. Once the patch is released, disable the **Merge pull request** setting. ## 1.0 release From 06744bfe012fdd580d1bfc52d2d3dcea92e31947 Mon Sep 17 00:00:00 2001 From: "John L. Peterson (Jack)" Date: Tue, 6 Aug 2024 08:46:26 -0400 Subject: [PATCH 3/3] Update .chloggen/ocb-migration.yaml Co-authored-by: Pablo Baeyens --- .chloggen/ocb-migration.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.chloggen/ocb-migration.yaml b/.chloggen/ocb-migration.yaml index 1c59d893b3a..a5b05552105 100644 --- a/.chloggen/ocb-migration.yaml +++ b/.chloggen/ocb-migration.yaml @@ -15,7 +15,7 @@ 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 will be released under open-telemetry/opentelemetry-collector-releases tagged as "cmd/builder/vX.XXX.X" +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]'