From 4ad7aff639ed4ac25f095039fafd03353e388665 Mon Sep 17 00:00:00 2001 From: mikeee Date: Mon, 23 Sep 2024 00:27:21 +0100 Subject: [PATCH 1/6] docs: release process Signed-off-by: mikeee --- 20240921-CIRS-release-process.md | 161 +++++++++++++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 20240921-CIRS-release-process.md diff --git a/20240921-CIRS-release-process.md b/20240921-CIRS-release-process.md new file mode 100644 index 0000000..4e5e002 --- /dev/null +++ b/20240921-CIRS-release-process.md @@ -0,0 +1,161 @@ +# Release process (automated) + +* Author(s): Mike Nguyen (@mikeee) - hey(at)mike.ee +* State: Draft +* Updated: 23-SEP-2024 + +## Overview + +This is a proposal to define a automated release process for Dapr. + +The automation will leverage existing release workflows for each repository +where implemented, with updates to add commit statuses to the context where +tests have passed. + +The new release process will be triggered by an issue being created with a +template defining the targets, once the required tests have passed a pull +request with the release notes will be created automatically and subject to +editing will kick off the release process when merged. + +All the Dapr repositories are in scope during the release process. + +## Background + +The release process is currently manual, this includes ensuring tests have +passed as well as kicking off a release. This removes the onus on maintainers on +to dedicate time during the endgame and the release team can perform releases +confidently with a defined workflow by maintainers. + +## Expectations + +* The release process will be triggered by a standardised issue template in the + main dapr/dapr repository. +* SDKs will be free to continue with releases where not part of a release run. +* Existing release workflows will be utilised where possible for testing and +releases. +* A daily trigger should be run to ensure that commit statuses are correct and +up to date. +* An automated pull request to the main dapr/dapr repository will be created +once tests are passing. This PR will contain release notes. +* The tagging and release process will be triggered by the merge of the release + notes PR. + +## Implementation Details + +### Design + +Repositories will have their workflows updated to include add commit statuses on +each commit reference where applicable e.g. release and main branches. The commit +reference is used to validate that it has passed the required tests and suitable +for release. This also reduces the burden of running extraneous jobs at +release time. + +#### Commit statuses + +Release branches going forwards for each repository should only be defined as +`release-X.YY` + +Runs will be triggered daily against all repositories using the latest commit +references for dapr & CLI for the latest release branch and the prior (YY-1). +The main branches will also be tested as not all repositories utilise release +branches. + +The context should be set to `release/tests` and have a state of: `error`, +`failure`, `pending` or `success`. The description should contain contextual +information for the run that will be displayed. + +#### Trigger - Release Issue Creation + +The process will be triggered by the creation of an issue from a template in +`dapr/dapr`. + +The release will use an unordered list defining inputs: + +```md +# Dapr Release Trigger + +* RC: No +* dapr/components-contrib: VERSION +* dapr/dapr: VERSION +* dapr/cli: VERSION +* dapr/dashboard: VERSION +* SDKs: + * go: VERSION + * rust: VERSION + * python: VERSION + * dotnet: VERSION + * java: VERSION + +``` + +The version should be specified as MAJOR.MINOR e.g. 1.15 + +The app will confirm whether there is an existing release, if so will provide +a patch release. If it is a RC release, it will increment the RC version unless +there is no existing RC in which case it will increment the PATCH version +number and append rc.0. + +Specifying no/nil version will result in it being excluded from the release +process. + +There will be a trigger response to display parsed the parsed markdown contents. + +#### GitHub Workflow + +The workflow will be split into 3 workflows: + +##### 1. Issue trigger + +This will follow an issue being opened, it will parse and respond to the issue +with a comment providing the parsed values/validity and provide a table of test +results. + +If the issue cannot be parsed, it will be closed. + +##### 2. Tests passing (repeated) + +A workflow will be run every 5 minutes for 5 hours (the maximum run time is +6 hours) until tests are passing or the deadline is reached. + +The issue comment will be maintained and updated after every job run. + +Once defined tests are passing, a PR will be raised with the release notes for +editing. + +If the deadline is reached, the issue will be closed and locked. + +##### 3. PR Merge + +The release team will propose changes to the PR for release notes if necessary +and subsequently approve and merge. + +This will trigger the tag and release process in this order: + +1. dapr/components-contrib +2. dapr/dapr +3. dapr/dashboard +4. dapr/cli +5. dapr/installer-bundle +6. SDKs +7. Operators / Shared / Taps etc. +8. dapr/quickstarts +9. dapr/samples +10. dapr/test-infra +11. dapr/docs +12. dapr/blog + +The status of the release will be reported on the issue and PR. + +## Completion Checklist + +* [ ] Workflows implemented + * [ ] Issue trigger + * [ ] Tests passing + * [ ] PR Merge +* [ ] Repository updates + * [ ] Release workflows confirmed/created + * [ ] Commit status jobs/steps added to test workflows +* [ ] Tests (Release process) + * [ ] Unit + * [ ] E2E +* [ ] Documentation From abaf4db77058da8440b67fa28c0cbb55def70524 Mon Sep 17 00:00:00 2001 From: mikeee Date: Mon, 23 Sep 2024 11:44:30 +0100 Subject: [PATCH 2/6] update: allow for version overrides Signed-off-by: mikeee --- 20240921-CIRS-release-process.md | 1 + 1 file changed, 1 insertion(+) diff --git a/20240921-CIRS-release-process.md b/20240921-CIRS-release-process.md index 4e5e002..b7d3eb4 100644 --- a/20240921-CIRS-release-process.md +++ b/20240921-CIRS-release-process.md @@ -89,6 +89,7 @@ The release will use an unordered list defining inputs: ``` The version should be specified as MAJOR.MINOR e.g. 1.15 +A full semantic version can be provided as an override. The app will confirm whether there is an existing release, if so will provide a patch release. If it is a RC release, it will increment the RC version unless From 3e366f6222218c9e444f9d8874f95f2633bc540c Mon Sep 17 00:00:00 2001 From: mikeee Date: Mon, 23 Sep 2024 20:07:40 +0100 Subject: [PATCH 3/6] define a new release repository Signed-off-by: mikeee --- 20240921-CIRS-release-process.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/20240921-CIRS-release-process.md b/20240921-CIRS-release-process.md index b7d3eb4..77fce53 100644 --- a/20240921-CIRS-release-process.md +++ b/20240921-CIRS-release-process.md @@ -12,6 +12,9 @@ The automation will leverage existing release workflows for each repository where implemented, with updates to add commit statuses to the context where tests have passed. +A new release repository will be maintained by the release team to manage the +release process - named `release`. + The new release process will be triggered by an issue being created with a template defining the targets, once the required tests have passed a pull request with the release notes will be created automatically and subject to @@ -29,7 +32,7 @@ confidently with a defined workflow by maintainers. ## Expectations * The release process will be triggered by a standardised issue template in the - main dapr/dapr repository. + main dapr/release repository. * SDKs will be free to continue with releases where not part of a release run. * Existing release workflows will be utilised where possible for testing and releases. @@ -149,7 +152,7 @@ The status of the release will be reported on the issue and PR. ## Completion Checklist -* [ ] Workflows implemented +* [ ] Workflows implemented (new release repository) * [ ] Issue trigger * [ ] Tests passing * [ ] PR Merge From 2fd114ecef8acb5302c1cf9508892f43d2cb9451 Mon Sep 17 00:00:00 2001 From: Mike Nguyen Date: Thu, 26 Sep 2024 10:39:27 +0100 Subject: [PATCH 4/6] minor grammatical fixes Signed-off-by: Mike Nguyen --- 20240921-CIRS-release-process.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/20240921-CIRS-release-process.md b/20240921-CIRS-release-process.md index 77fce53..2ceeaa4 100644 --- a/20240921-CIRS-release-process.md +++ b/20240921-CIRS-release-process.md @@ -6,7 +6,7 @@ ## Overview -This is a proposal to define a automated release process for Dapr. +This is a proposal to define an automated release process for Dapr. The automation will leverage existing release workflows for each repository where implemented, with updates to add commit statuses to the context where @@ -25,7 +25,7 @@ All the Dapr repositories are in scope during the release process. ## Background The release process is currently manual, this includes ensuring tests have -passed as well as kicking off a release. This removes the onus on maintainers on +passed as well as kicking off a release. This removes the onus on maintainers to dedicate time during the endgame and the release team can perform releases confidently with a defined workflow by maintainers. @@ -33,7 +33,7 @@ confidently with a defined workflow by maintainers. * The release process will be triggered by a standardised issue template in the main dapr/release repository. -* SDKs will be free to continue with releases where not part of a release run. +* SDKs will be free to continue with releases that are not part of a release run. * Existing release workflows will be utilised where possible for testing and releases. * A daily trigger should be run to ensure that commit statuses are correct and @@ -49,13 +49,13 @@ once tests are passing. This PR will contain release notes. Repositories will have their workflows updated to include add commit statuses on each commit reference where applicable e.g. release and main branches. The commit -reference is used to validate that it has passed the required tests and suitable +reference is used to validate that it has passed the required tests and is suitable for release. This also reduces the burden of running extraneous jobs at release time. #### Commit statuses -Release branches going forwards for each repository should only be defined as +Release branches going forward for each repository should only be defined as `release-X.YY` Runs will be triggered daily against all repositories using the latest commit @@ -94,15 +94,15 @@ The release will use an unordered list defining inputs: The version should be specified as MAJOR.MINOR e.g. 1.15 A full semantic version can be provided as an override. -The app will confirm whether there is an existing release, if so will provide -a patch release. If it is a RC release, it will increment the RC version unless +The app will confirm whether there is an existing release, and if so will provide +a patch release. If it is an RC release, it will increment the RC version unless there is no existing RC in which case it will increment the PATCH version number and append rc.0. Specifying no/nil version will result in it being excluded from the release process. -There will be a trigger response to display parsed the parsed markdown contents. +There will be a trigger response to display the parsed markdown contents. #### GitHub Workflow @@ -111,7 +111,7 @@ The workflow will be split into 3 workflows: ##### 1. Issue trigger This will follow an issue being opened, it will parse and respond to the issue -with a comment providing the parsed values/validity and provide a table of test +with a comment providing the parsed values/validity and a table of test results. If the issue cannot be parsed, it will be closed. @@ -131,7 +131,7 @@ If the deadline is reached, the issue will be closed and locked. ##### 3. PR Merge The release team will propose changes to the PR for release notes if necessary -and subsequently approve and merge. +and subsequently, approve and merge. This will trigger the tag and release process in this order: From 060d91f0e3a18a7beaf6f028bdf92c75bebff768 Mon Sep 17 00:00:00 2001 From: Mike Nguyen Date: Thu, 26 Sep 2024 11:40:39 +0100 Subject: [PATCH 5/6] add js sdk Signed-off-by: Mike Nguyen --- 20240921-CIRS-release-process.md | 1 + 1 file changed, 1 insertion(+) diff --git a/20240921-CIRS-release-process.md b/20240921-CIRS-release-process.md index 2ceeaa4..819fd4a 100644 --- a/20240921-CIRS-release-process.md +++ b/20240921-CIRS-release-process.md @@ -88,6 +88,7 @@ The release will use an unordered list defining inputs: * python: VERSION * dotnet: VERSION * java: VERSION + * js: VERSION ``` From 05a2e038347fce98f8bee7ed4b267ea6db2884fc Mon Sep 17 00:00:00 2001 From: Mike Nguyen Date: Fri, 27 Sep 2024 17:32:59 +0100 Subject: [PATCH 6/6] clarify release trigger Signed-off-by: Mike Nguyen --- 20240921-CIRS-release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/20240921-CIRS-release-process.md b/20240921-CIRS-release-process.md index 819fd4a..e114d3b 100644 --- a/20240921-CIRS-release-process.md +++ b/20240921-CIRS-release-process.md @@ -70,7 +70,7 @@ information for the run that will be displayed. #### Trigger - Release Issue Creation The process will be triggered by the creation of an issue from a template in -`dapr/dapr`. +`dapr/release`. The label MUST also be release-eng/release. The release will use an unordered list defining inputs: