-
Notifications
You must be signed in to change notification settings - Fork 96
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.
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
Monitor release progress from single workflow #7037
Closed
willdavsmith
wants to merge
5
commits into
radius-project:main
from
willdavsmith:willdavsmith/rel-docs-samples
Closed
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -187,3 +187,108 @@ jobs: | |
| run: | | ||
| ./radius/.github/scripts/release-create-tag-and-branch.sh recipes ${{ steps.get-version.outputs.release-version }} ${{ steps.get-version.outputs.release-branch-name }} | ||
| if: success() | ||
|
|
||
|
|
||
| - name: Wait for the radius-project/radius Build and Test workflow to complete | ||
| if: always() | ||
| uses: willdavsmith/[email protected] | ||
| with: | ||
| ref: tags/${{ steps.get-version.outputs.release-version }} | ||
| check-name: 'Build and Test' | ||
| repo-token: ${{ secrets.GITHUB_TOKEN }} | ||
| wait-interval: 60 | ||
| - name: Wait for the radius-project/radius Assets workflow to complete | ||
| if: always() | ||
| uses: willdavsmith/[email protected] | ||
| with: | ||
| ref: tags/${{ steps.get-version.outputs.release-version }} | ||
| check-name: 'Assets' | ||
| repo-token: ${{ secrets.GITHUB_TOKEN }} | ||
| wait-interval: 60 | ||
| - name: Wait for the radius-project/bicep Radius Build workflow to complete | ||
| if: always() | ||
| uses: willdavsmith/[email protected] | ||
| with: | ||
| ref: tags/${{ steps.get-version.outputs.release-version }} | ||
| repo: radius-project/bicep | ||
| check-name: 'Radius Build' | ||
| repo-token: ${{ secrets.GITHUB_TOKEN }} | ||
| wait-interval: 60 | ||
| - name: Wait for the radius-project/deployment-engine Build workflow to complete | ||
| if: always() | ||
| uses: willdavsmith/[email protected] | ||
| with: | ||
| ref: tags/${{ steps.get-version.outputs.release-version }} | ||
| repo: radius-project/deployment-engine | ||
| check-name: 'Build' | ||
| repo-token: ${{ secrets.GITHUB_TOKEN }} | ||
| wait-interval: 60 | ||
| - name: Wait for the radius-project/recipes Publish Recipes workflow to complete | ||
| if: always() | ||
| uses: willdavsmith/[email protected] | ||
| with: | ||
| ref: tags/${{ steps.get-version.outputs.release-version }} | ||
| repo: radius-project/recipes | ||
| check-name: 'Publish Recipes' | ||
| repo-token: ${{ secrets.GITHUB_TOKEN }} | ||
| wait-interval: 60 | ||
|
|
||
| - name: Release verification ${{ steps.get-version.outputs.release-version }} | ||
| uses: convictional/[email protected] | ||
| with: | ||
| owner: radius-project | ||
| repo: radius | ||
| github_token: ${{ secrets.GH_RAD_CI_BOT_PAT }} | ||
| github_user: rad-ci-bot | ||
| workflow_file_name: release-verification.yaml | ||
| ref: edge | ||
| wait_interval: 60 | ||
| client_payload: '{ "version": "${{ steps.get-version.outputs.release-version-number }}" }' | ||
| propagate_failure: true | ||
| trigger_workflow: true | ||
| wait_workflow: true | ||
| - name: Sample validation ${{ steps.get-version.outputs.release-version }} | ||
| uses: convictional/[email protected] | ||
| with: | ||
| owner: radius-project | ||
| repo: samples | ||
| github_token: ${{ secrets.GH_RAD_CI_BOT_PAT }} | ||
| github_user: rad-ci-bot | ||
| workflow_file_name: test.yaml | ||
| ref: edge | ||
| wait_interval: 60 | ||
| client_payload: '{ "version": "${{ steps.get-version.outputs.release-version-number }}" }' | ||
| propagate_failure: true | ||
| trigger_workflow: true | ||
| wait_workflow: true | ||
|
|
||
| - name: Release docs ${{ steps.get-version.outputs.release-version }} | ||
| if: success() && ${{ endsWith(steps.get-version.outputs.release-version, '.0') }} | ||
| uses: convictional/[email protected] | ||
| with: | ||
| owner: radius-project | ||
| repo: docs | ||
| github_token: ${{ secrets.GH_RAD_CI_BOT_PAT }} | ||
| github_user: rad-ci-bot | ||
| workflow_file_name: release.yaml | ||
| ref: edge | ||
| wait_interval: 60 | ||
| client_payload: '{ "version": "${{ steps.get-version.outputs.release-version-number }}" }' | ||
| propagate_failure: true | ||
| trigger_workflow: true | ||
| wait_workflow: true | ||
| - name: Release samples ${{ steps.get-version.outputs.release-version }} | ||
| if: success() && ${{ endsWith(steps.get-version.outputs.release-version, '.0') }} | ||
| uses: convictional/[email protected] | ||
| with: | ||
| owner: radius-project | ||
| repo: samples | ||
| github_token: ${{ secrets.GH_RAD_CI_BOT_PAT }} | ||
| github_user: rad-ci-bot | ||
| workflow_file_name: release.yaml | ||
| ref: edge | ||
| wait_interval: 60 | ||
| client_payload: '{ "release_version": "${{ steps.get-version.outputs.release-version-number }}" }' | ||
| propagate_failure: true | ||
| trigger_workflow: true | ||
| wait_workflow: true | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,104 +12,112 @@ If we find issues in validation, we can create additional RC releases until we f | |
|
|
||
| Follow the steps below to create an RC release. | ||
|
|
||
| 1. Clone the [project-radius/radius](https://github.com/project-radius/radius) repo locally. | ||
| 1. Clone the [radius-project/radius](https://github.com/radius-project/radius) repo locally, or use your existing local copy. | ||
| ``` | ||
| git clone [email protected]:radius-project/radius.git | ||
| ``` | ||
|
|
||
| 1. Create a new branch from `main`. | ||
| 1. In your local branch, update the `versions.yaml` file in the project-radius/radius repo | ||
| The `versions.yaml` file is a declarative version tracking file that the Radius community maintains. Update it to reflect the new release candidate version that we would like to release. ([Example](https://github.com/project-radius/radius/pull/6077/files)) | ||
| 1. Push these changes to a remote branch and create a pull request against `main`. | ||
| 1. After maintainer approval, merge the pull request to `main`. | ||
| 1. Verify that [GitHub actions triggers a build](https://github.com/project-radius/radius/actions), and that the build completes. This will build and push Radius assets to [GHCR](https://github.com/orgs/radius-project/packages) | ||
| 1. In the project-radius/radius repo, run the [Release verification](https://github.com/radius-project/radius/actions/workflows/release-verification.yaml) workflow. Run the workflow from the release branch (format: release/x.y) and use the Radius RC release version number being released. | ||
| ``` | ||
| git checkout main | ||
| git checkout -b <USERNAME>/<BRANCHNAME> | ||
| ``` | ||
|
|
||
| ### Test tutorials and samples | ||
| 1. In your local branch, update the `versions.yaml` file to to reflect the new release candidate version that we would like to release. The `versions.yaml` file is a declarative version tracking file that the Radius community maintains ([Example](https://github.com/radius-project/radius/pull/6077/files)). | ||
|
|
||
| In the project-radius/samples repo, run the [Test Samples](https://github.com/project-radius/samples/actions/workflows/test.yaml) workflow. Run the workflow from the edge branch and using the Radius release or pre-release version number being released. | ||
| 1. Push these changes to a remote branch and create a pull request against `main`. | ||
| ``` | ||
| git push origin <USERNAME>/<BRANCHNAME> | ||
| ``` | ||
|
|
||
| > For now, this is a manual task. Soon, this workflow will be triggered automatically. | ||
| > There is a possibility that the workflow run failed because of flaky tests. Try re-running, and if the failure is persistent, then there should be further investigation. | ||
| 1. After maintainer approval, merge the pull request to `main`. | ||
|
|
||
| If this workflow run fails, or if we encounter an issue with an RC release, please refer to "Patching" below. | ||
| 1. There should now be a GitHub workflow run in progress [here](https://github.com/radius-project/radius/actions/workflows/release.yaml) that was triggered by the `vx.y.z-rc1` tag. Monitor this workflow to ensure that it completes successfully. If it does, then the release candidate has been created and successfully validated. | ||
|
|
||
| ### Creating the final release | ||
|
|
||
| If sample validation passes, we can start the process of creating the final release. | ||
|
|
||
| 1. In the `radius-project/bicep` repo, in the release branch, change the `version.json` version to the new release number. Create a pull request and merge this change into the bicep-extensibility and release/\<release-version\> branch. | ||
|
|
||
| 1. Go through steps 1-4 of "Creating an RC release" above, substituting the final release version instead of the RC version. For example, if the RC version number is `0.1.0-rc1`, the final release version would be `0.1.0`. | ||
| 1. Clone the [radius-project/bicep](https://github.com/radius-project/bicep) repo locally, or use your existing local copy. | ||
| ``` | ||
| git clone [email protected]:radius-project/radius.git | ||
| ``` | ||
|
|
||
| 1. In this PR, create a new release note document in the [release-notes](../../release-notes/) directory using the automatically generated release notes comment. Follow the directory's README.md for instructions on how to create a new release note document. Include this file in the release version pull request. [Example](https://github.com/project-radius/radius/pull/6092/files) | ||
| 1. Create a new branch from `bicep-extensibility`. | ||
| ``` | ||
| git checkout bicep-extensibility | ||
| git checkout -b <USERNAME>/<BRANCHNAME> | ||
| ``` | ||
|
|
||
| 1. Create a PR to merge into the release branch (format: release/x.y) in the radius repo. Cherry-pick the `version.yaml` changes and the release notes from the previous step in this PR. This will ensure that the version changes and release notes are included in the release branch. [Example](https://github.com/radius-project/radius/pull/6114/files) | ||
| 1. In your local branch, update the `version.json` file. | ||
| Update it to reflect the new release version that we would like to release ([Example](https://github.com/radius-project/bicep/pull/703/files)). | ||
|
|
||
| ```bash | ||
| git cherry-pick -x <COMMIT HASH> | ||
| 1. Push these changes to a remote branch and create a pull request against `bicep-extensibility`. | ||
| ``` | ||
| git push origin <USERNAME>/<BRANCHNAME> | ||
| ``` | ||
|
|
||
| 1. In the project-radius/docs repository, run the [Release docs](https://github.com/project-radius/docs/actions/workflows/release.yaml) workflow. | ||
|
|
||
| 1. In the project-radius/docs repository, run the [Release samples](https://github.com/project-radius/samples/actions/workflows/release.yaml) workflow. | ||
| 1. After maintainer approval, merge the pull request to `bicep-extensiblity`. | ||
|
|
||
| 1. In the project-radius/radius repo, run the [Release verification](https://github.com/radius-project/radius/actions/workflows/release-verification.yaml) workflow. Run the workflow from the release branch (format: release/x.y) and use the Radius release version number being released. | ||
| 1. Create a new branch from the release branch we want to release. The release branch should already exist in the repo. Release branches are in the format `release/x.y`. | ||
| ``` | ||
| git checkout release/0.<VERSION> | ||
| git checkout -b <USERNAME>/<BRANCHNAME> | ||
| ``` | ||
|
|
||
| 1. Download the Radius Bicep .vsix file from here: https://github.com/radius-project/bicep/releases/download/\<VERSION\>/rad-vscode-bicep.vsix, replacing the \<VERSION\> as necessary. | ||
| 1. Cherry-pick the `version.json` changes from the previous steps in this PR. This will ensure that the version changes are included in the release branch ([Example](https://github.com/radius-project/bicep/pull/704/files)). You can get the commit hash by running `git log --oneline` in the main branch. PLEASE USE `-x` HERE TO ENSURE VERSION HISTORY IS PRESERVED. | ||
| ``` | ||
| git cherry-pick -x <COMMIT HASH> | ||
| ``` | ||
|
|
||
| 1. Upload the Radius Bicep .vsix to the [VS marketplace](https://marketplace.visualstudio.com/manage). You may need access permissions, if so, ask a maintainer. Click on the ... for Radius Bicep, then Update, then upload the .vsix file. The site will verify it then the version number should be updated to the right one. | ||
| 1. Create a PR to merge into the release branch in the bicep repo. | ||
|
|
||
| ## How releases work | ||
| 1. After maintainer approval, merge the pull request to the release branch. | ||
|
|
||
| Each release belongs to a *channel* named `<major>.<minor>`. Releases will only interact with assets from their channel. For example, the `0.1` `rad` CLI will: | ||
| 1. Move to your local copy of the `radius-project/radius` repo. | ||
|
|
||
| - Download `rad-bicep` from the `0.1` channel | ||
| - Create an environment using the `0.1` version of the RP and environment setup script | ||
| 1. Create a new branch from `main`. | ||
|
|
||
| > ⚠️ Compatibility ⚠️ | ||
| At this time we do not guarantee compatibility across releases or provide a migration path. For example, the behavior of a `0.1` `rad` CLI talking to a `0.2` control plane is unspecifed. We expect the project to change too frequently to provide compatibility guarantees at this time. | ||
| 1. In your local branch, update the `versions.yaml` file to to reflect the new release version that we would like to release ([Example](https://github.com/radius-project/radius/pull/6992/files#diff-1c4cd801df522f4a92edbfb0fea95364ed074a391ea47c284ddc078f512f7b6a)). | ||
|
|
||
| Conceptually we scope channels to a major+minor pair because this allows us to freely patch assets as needed without needing to change the intermediate pieces. For example pushing a `v0.1.1` tag will update the assets in the `v0.1` channel. This works as long as it is a *true* patch release and maintains compatibility. | ||
| 1. Push these changes to a remote branch and create a pull request against `main`. | ||
|
|
||
| ## Patching | ||
| 1. In this PR, there will be an automatically-generated release notes comment. Create a new release note document in the [release-notes](../../release-notes/) directory using this automatically generated release notes comment. Follow the directory's README.md for instructions on how to create a new release note document. Include this file in the release version pull request ([Example](https://github.com/radius-project/radius/pull/6092/files)). | ||
|
|
||
| Let's say we have a bug in a release that needs to be patched for an already-created release. | ||
| 1. After maintainer approval, merge the pull request to `main`. | ||
|
|
||
| 1. In the `radius-project/bicep` repo, in the release branch, change the `version.json` version to the new release number. Create a pull request and merge this change. | ||
| 1. Create a PR to merge into the release branch (format: `release/x.y`) in the radius repo. Cherry-pick the commit containing the `versions.yaml` changes and the release notes from the previous steps in this PR. You can get the commit hash by running `git log --oneline` in the main branch. This will ensure that the version changes and release notes are included in the release branch ([Example](https://github.com/radius-project/radius/pull/6114/files)). PLEASE USE `-x` HERE TO ENSURE VERSION HISTORY IS PRESERVED. | ||
| ```bash | ||
| git cherry-pick -x <COMMIT HASH> | ||
| ``` | ||
|
|
||
| 1. Go through steps 1-4 of "Creating an RC release" above on the `main` branch, substituting the patch release version instead of the final release version. For example, if the final release version number is 0.1.0, the patch release version would be 0.1.1. | ||
| 1. After maintainer approval, merge the pull request to `main`. | ||
|
|
||
| 1. After creating the pull request, there should be an automatically generated release notes comment. Create a new release note document in the [release-notes](../../release-notes/) directory. Follow the directory's README.md for instructions on how to create a new patch release note document. Include this file in the release version pull request. [Example](https://github.com/project-radius/radius/pull/6092/files) | ||
| 1. There should now be a GitHub workflow run in progress [here](https://github.com/radius-project/radius/actions/workflows/release.yaml) that was triggered by the `vx.y.z` tag. Monitor this workflow to ensure that it completes successfully. If it does, then the release candidate has been created and successfully validated. | ||
|
|
||
| 1. Now we can start patching the release branch. Make sure the commit that we want to add to a patch is merged and validated in `main` first if it affects `main`. | ||
| 1. Download the Radius Bicep .vsix file from here: https://github.com/radius-project/bicep/releases. Scroll down to the most recent release and download the .vsix file. | ||
|
|
||
| 1. Create a new branch based off of the release branch we want to patch. Ex: | ||
| 1. Upload the Radius Bicep .vsix to the [VS marketplace](https://marketplace.visualstudio.com/manage). You may need access permissions, if so, ask a maintainer. Click on the ... for Radius Bicep, then Update, then upload the .vsix file. The site will verify it then the version number should be updated to the right one. | ||
|
|
||
| ```bash | ||
| git checkout release/0.<VERSION> | ||
| git checkout -b <USERNAME>/<BRANCHNAME> | ||
| ``` | ||
| ## Patching | ||
|
|
||
| 1. Cherry-pick the commit that is on `main` onto the branch. PLEASE USE `-x` HERE TO ENSURE VERSION HISTORY IS PRESERVED. | ||
| Let's say we have a bug in a release that needs to be patched for an already-created release. | ||
|
|
||
| ```bash | ||
| git cherry-pick -x <COMMIT HASH> | ||
| ``` | ||
| 1. Go through all of the steps in [Creating the final release](#creating-the-final-release), substituting in the patch version for the release version. For example, if the current release version is `0.1.0`, the patch version would be `0.1.1`. | ||
|
|
||
| 1. If breaking changes have been made to our Bicep fork: | ||
|
|
||
| Update the file radius/.github/workflows/validate-bicep.yaml to use the release version (eg. v0.21) instead of edge for validating the biceps in the docs and samples repositories. Also, modify the version from `env.REL_CHANNEL` to `<major>.<minor>` (eg. `0.21`) for downloading the `rad-bicep-corerp`. | ||
|
|
||
| 1. Cherry-pick the `version.yaml` changes and release notes onto the branch from the PR opened against the main. This will ensure that the release notes are included in the release branch. [Example](https://github.com/radius-project/radius/pull/6114/files). The release branch should now contain all needed patch changes, an updated release version, and patch release notes. | ||
|
|
||
| 1. Push the commits to the remote and create a pull request targeting the release branch. | ||
| ## How releases work | ||
|
|
||
| ```bash | ||
| git push origin <USERNAME>/<BRANCHNAME> | ||
| ``` | ||
| Each release belongs to a *channel* named `<major>.<minor>`. Releases will only interact with assets from their channel. For example, the `0.1` `rad` CLI will: | ||
|
|
||
| 1. Merge the release branch PR into the release branch (this is the branch with the patch changes, updated patch version, and release notes). Then, merge the PR created against `main` into the main branch (this will only contain the updated patch version and the release notes). The release branch changes must be merged before the PR is merged into the main since the workflow in the main branch builds the release based on the head of the release branch. If the changes are not merged first to the release branch and then to the main branch, the patch release will not contain the necessary code fixes. | ||
| - Download `rad-bicep` from the `0.1` channel | ||
| - Create an environment using the `0.1` version of the RP and environment setup script | ||
|
|
||
| 1. Verify that a patch release was created on Github Releases for the current patch version. [Example](https://github.com/radius-project/radius/releases) | ||
| > ⚠️ Compatibility ⚠️ | ||
| At this time we do not guarantee compatibility across releases or provide a migration path. For example, the behavior of a `0.1` `rad` CLI talking to a `0.2` control plane is unspecifed. We expect the project to change too frequently to provide compatibility guarantees at this time. | ||
|
|
||
| 1. Rerun steps 8-9 described [here](#creating-the-final-release) to upload updated rad-vscode-bicep.vsix file | ||
| Conceptually we scope channels to a major+minor pair because this allows us to freely patch assets as needed without needing to change the intermediate pieces. For example pushing a `v0.1.1` tag will update the assets in the `v0.1` channel. This works as long as it is a *true* patch release and maintains compatibility. | ||
|
|
||
| ## Cadence | ||
|
|
||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of creating our own script, I would consider using the following action:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait-on-check is promising for this scenario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wait-on-check doesn't support different repos, so I forked and added these changes: lewagon/wait-on-check-action@master...willdavsmith:wait-on-check-action:master