Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: clarify automation in release workflow #13851

Merged
merged 6 commits into from
Dec 11, 2024
Merged

docs: clarify automation in release workflow #13851

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
737698d
docs: clarify automation in release workflow
inge4pres Aug 8, 2024
b9404dc
fix formatting
inge4pres Aug 8, 2024
4d12a68
spelling fix
inge4pres Aug 14, 2024
c193984
better phrasing
inge4pres Dec 9, 2024
e3911a2
fix important callout
inge4pres Dec 9, 2024
13c9855
Merge branch 'main' into dev-docs/release-clarify-workflow
inge4pres Dec 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 15 additions & 10 deletions dev_docs/RELEASES.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,15 +17,17 @@ For patch releases, only the version on the existing major and minor version bra

* Trigger release workflow manually
* For **patch releases**: run the [`run-patch-release`](https://github.com/elastic/apm-server/actions/workflows/run-patch-release.yml) workflow (In "Use workflow from", select `main` branch. Then in "The version", specify the **upcoming** patch release version - es: on `8.14.2` feature freeze you will use `8.14.2`).
This workflow will: create the release branch; update version across codebase; commit and create PR targeting the release branch.
Release notes for patch releases **must be manually added** (PR should target `main` branch and backported to the release branch):
This workflow will: create the `update-<VERSION>` branch, update version constants across the codebase and create a PR targeting the release branch.
Release notes for patch releases **must be manually added** at least one day before release.
Create a PR targeting the `main` branch and add the backport label for the release branch.
To add release notes:
* Add a new section to the existing release notes file ([Sample PR](https://github.com/elastic/apm-server/pull/12680)).
* Review the [changelogs/head](https://github.com/elastic/apm-server/tree/main/changelogs/head.asciidoc) file and move relevant changelog entries from `head.asciidoc` to `release_version.asciidoc` if the change is backported to release_version. If changes do not apply to the version being released, keep them in the `head.asciidoc` file.
* Review the commits in the release to ensure all changes are reflected in the release notes. Check for backported changes without release notes in `release_version.asciidoc`.
* Add your PR to the documentation release issue ([Sample Issue](https://github.com/elastic/dev/issues/2485)).
* Add your PR to the documentation release issue in the [`elastic/dev`](https://github.com/elastic/dev/issues?q=is%3Aissue%20state%3Aopen%20label%3Adocs) repo ([Sample Issue](https://github.com/elastic/dev/issues/2485)).
* The PR should be merged the day before release.
* For **minor releases**: run the [`run-minor-release`](https://github.com/elastic/apm-server/actions/workflows/run-minor-release.yml) workflow (In "Use workflow from", select `main` branch. Then in "The version", specify the minor release version the release is for).
This workflow will: create the release branch; update the changelog for the release branch and open a PR targeting the release branch titled `<major>.<minor>: update docs`; create a PR on `main` titled `<major>.<minor>: update docs, mergify, versions and changelogs`. Before merging them compare commits between latest minor and the new minor versions and ensure all relevant PRs have been included in the Changelog. If not, amend it in both PRs. Request and wait a PR review from the team before merging.
* For **minor releases**: run the [`run-minor-release`](https://github.com/elastic/apm-server/actions/workflows/run-minor-release.yml) workflow (In "Use workflow from", select `main` branch. Then in "The version", specify the minor release version the release is for).
This workflow will: create a new release branch using the stack version (X.Y); update the changelog for the release branch and open a PR targeting the release branch titled `<major>.<minor>: update docs`; create a PR on `main` titled `<major>.<minor>: update docs, mergify, versions and changelogs`. Before merging them compare commits between latest minor and the new minor versions and ensure all relevant PRs have been included in the Changelog. If not, amend it in both PRs. Request and wait a PR review from the team before merging.
* The Release Manager will ping the team to align the release process

* Update dependencies
Expand All @@ -49,8 +51,8 @@ For patch releases, only the version on the existing major and minor version bra
* A link to all PRs in the APM Server repository that need to be tested manually to create an overview over the PRs that need testing.
Use the `test-plan` label and the version label (create it if it does not exist). For example, [this was 8.13.0 test plan](https://github.com/elastic/apm-server/issues/12822)
and here you can find [all previous test plans](https://github.com/elastic/apm-server/issues?q=label%3Atest-plan+is%3Aclosed).
What we aim for is testing all functional changes applied to the new version. Review any PR updating `elastic/go-docappender` and `elastic/apm-data` dependencies, as some functional changes happens through these dependencies.
Any non-functional change or any change that is already covered by automated tests must not be included.
What we aim for is testing all functional changes applied to the new version. Review any PR updating `elastic/go-docappender` and `elastic/apm-data` dependencies, as some functional changes happens through these dependencies.
Any non-functional change or any change already covered by automated tests must not be included.
* Add other test cases that require manual testing, such as test scenarios on ESS, that are not covered by automated tests or OS compatibility smoke tests for supporting new operating systems.

## Between feature freeze and release
Expand All @@ -68,11 +70,14 @@ For patch releases, only the version on the existing major and minor version bra

## On release day

* New branches need to be added to `conf.yml` in the `elastic/docs` repo. [Example](https://github.com/elastic/docs/pull/893/files#diff-4a701a5adb4359c6abf9b8e1cb38819fR925). **This is handled by the docs release manager.**
* For **minor releases**: new branches need to be added to `conf.yml` in the `elastic/docs` repo. [Example](https://github.com/elastic/docs/pull/893/files#diff-4a701a5adb4359c6abf9b8e1cb38819fR925). **This is handled by the docs release manager.**

* A new [tag](https://github.com/elastic/apm-server/releases) will automatically be created on GitHub.
* For **patch releases**: if there is an open PR that bumps the version, merge the PR (it may have been created by the GitHub workflow as part of the steps in the ["Day after feature freeze"](#day-after-feature-freeze) section).
If there is no PR, create one.
> [!IMPORTANT]
> Only merge the PRs once pinged on Slack by the Release Manager on release date in the #mission-control channel

* Bump the version in anticipation of the next release, e.g. [after 8.13.3 release](https://github.com/elastic/apm-server/pull/13066) bump to 8.13.4. **Prepare this PR ahead of time** but only merge it once pinged by the Release Manager on release date.
* A new [tag](https://github.com/elastic/apm-server/releases) will automatically be created on GitHub.

## When compatibility between Agents & Server changes

Expand Down
Loading