feat: simplify patch release workflow#8196
Conversation
This commit simplifies the `patch-release.yml` workflow by replacing the inline release steps with the reusable `publish-release` action. This improves maintainability and consistency with other release workflows.
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
|
Size Change: -2 B (0%) Total Size: 13.2 MB ℹ️ View Unchanged
|
This commit introduces automated patch versioning for releases. The `get-release-version.js` script can now calculate the next patch version for `stable` and `preview` releases. The `patch-release.yml` workflow has been updated to use this new functionality, removing the need for manual version input and streamlining the patch release process.
This commit updates the `releases.md` file to reflect the new automated release promotion process. It also clarifies the distinction between the weekly promotion and the patch release workflows.
This commit corrects the `patch-release.yml` workflow to use the `github.event.inputs.ref` as the `release-branch` for the reusable `publish-release` action. This aligns with the intended simplification of the workflow.
7f418c2 to
c309bc5
Compare
This commit fixes the `patch-release.yml` workflow by: 1. Re-introducing the "Run Tests" step, which was inadvertently removed. 2. Removing the undefined `force_skip_tests` and `gemini_api_key` inputs from the call to the `publish-release` action.
This commit refactors the release workflows by moving common steps (Git configuration, branch creation, versioning, committing, and pushing) into the `publish-release` reusable action. The `promote-release` and `patch-release` workflows have been simplified to use this centralized logic, improving maintainability and consistency.
This commit updates the `nightly-release.yml` workflow to align with the centralized logic in the `publish-release` reusable action. It removes the redundant `release-branch` parameter and adds a failure handling step for consistency.
This commit moves the "Create Issue on Failure" step into the `publish-release` reusable action. All release workflows have been updated to use this centralized logic, which improves consistency and maintainability.
This commit introduces a new reusable action, `run-tests`, to standardize the testing process across all release workflows. The `patch-release`, `promote-release`, and `nightly-release` workflows have all been updated to use this new action, ensuring that tests are run consistently before any release is published.
This commit adds a new `lint:all` script to `package.json` that mirrors the linting steps in the CI pipeline. This allows developers to run all linting checks locally, including `actionlint`, `shellcheck`, and `yamllint`. A pre-lint step is included to check for the required tools and provide installation instructions if they are missing.
This commit replaces the various linting scripts in `package.json` with a single, robust Node.js script (`scripts/lint.js`). This new script fully replicates the CI linting process by: 1. Detecting the user's OS and architecture. 2. Downloading and using the exact same versions of `actionlint` and `shellcheck` as the CI. 3. Automatically installing `yamllint` via pip. 4. Running all linters (`eslint`, `actionlint`, `shellcheck`, `yamllint`) in the correct sequence. This ensures that developers can run a comprehensive and CI-consistent linting process locally with a single command.
5ab5706 to
5b366f1
Compare
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
|
I think this is ready to go. This provides a github action that will let a user kick off a patch release AFTER they have cherry picked and created the right branches. In this pr that work is still manual. in #8202 we make that better as follow on work. We also try and capture a bunch of the linting tools locally as it is extremely frustrating to have them fail on ci with out a way to mirror that behavior locally. I'm certain the |
Applied prettier formatting to scripts/lint.js
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
8172b96 to
3c1e570
Compare
8099c45 to
a25b35e
Compare
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Richie Foreman <richie.foreman@gmail.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Co-authored-by: Richie Foreman <richie.foreman@gmail.com>
This PR simplifies the patch-release.yml workflow by using the reusable publish-release action.