From c51dc4e12199ab571ebfc44bf9baeb44eb1b48e2 Mon Sep 17 00:00:00 2001 From: PPawlowski Date: Wed, 22 Apr 2026 11:44:56 +0200 Subject: [PATCH 1/8] Add release workflow with required config files --- .github/release-please-config.json | 52 +++++++++++++++++++++++++++ .github/release-please-manifest.json | 13 +++++++ .github/workflows/release-please.yaml | 52 +++++++++++++++++++++++++++ 3 files changed, 117 insertions(+) create mode 100644 .github/release-please-config.json create mode 100644 .github/release-please-manifest.json create mode 100644 .github/workflows/release-please.yaml diff --git a/.github/release-please-config.json b/.github/release-please-config.json new file mode 100644 index 0000000..ae159fd --- /dev/null +++ b/.github/release-please-config.json @@ -0,0 +1,52 @@ +{ + "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", + "separator": "/", + "include-component-in-tag": true, + "include-v-in-tag": true, + "release-type": "simple", + "skip-github-release": true, + "changelog-path": "CHANGELOG.md", + "packages": { + ".github/workflows/build_container_image": { + "component": "build_container_image", + "include-paths": [".github/workflows/build_container_image.yml"] + }, + ".github/workflows/build_node_package": { + "component": "build_node_package", + "include-paths": [".github/workflows/build_node_package.yml"] + }, + ".github/workflows/build_node_package_with_pgsql": { + "component": "build_node_package_with_pgsql", + "include-paths": [".github/workflows/build_node_package_with_pgsql.yml"] + }, + ".github/workflows/deploy_container_image": { + "component": "deploy_container_image", + "include-paths": [".github/workflows/deploy_container_image.yml"] + }, + ".github/workflows/deploy_helm_chart": { + "component": "deploy_helm_chart", + "include-paths": [".github/workflows/deploy_helm_chart.yml"] + }, + ".github/workflows/merge_multiarch_images": { + "component": "merge_multiarch_images", + "include-paths": [".github/workflows/merge_multiarch_images.yml"] + }, + ".github/workflows/publish_node_package": { + "component": "publish_node_package", + "include-paths": [".github/workflows/publish_node_package.yml"] + }, + ".github/workflows/sast_scan": { + "component": "sast_scan", + "include-paths": [".github/workflows/sast_scan.yaml"] + }, + "actions/npm_test": { + "component": "npm_test" + }, + "actions/scan_container_image": { + "component": "scan_container_image" + }, + "actions/update-nr-flows": { + "component": "update-nr-flows" + } + } +} diff --git a/.github/release-please-manifest.json b/.github/release-please-manifest.json new file mode 100644 index 0000000..953a5c8 --- /dev/null +++ b/.github/release-please-manifest.json @@ -0,0 +1,13 @@ +{ + ".github/workflows/build_container_image": "1.0.0", + ".github/workflows/build_node_package": "1.0.0", + ".github/workflows/build_node_package_with_pgsql": "1.0.0", + ".github/workflows/deploy_container_image": "1.0.0", + ".github/workflows/deploy_helm_chart": "1.0.0", + ".github/workflows/merge_multiarch_images": "1.0.0", + ".github/workflows/publish_node_package": "1.0.0", + ".github/workflows/sast_scan": "1.0.0", + "actions/npm_test": "1.0.0", + "actions/scan_container_image": "1.0.0", + "actions/update-nr-flows": "1.0.0" +} diff --git a/.github/workflows/release-please.yaml b/.github/workflows/release-please.yaml new file mode 100644 index 0000000..244ad73 --- /dev/null +++ b/.github/workflows/release-please.yaml @@ -0,0 +1,52 @@ +name: Prepare release + +on: + push: + branches: [main] + workflow_dispatch: + +permissions: + contents: write + pull-requests: write + issues: write + +jobs: + release-please: + runs-on: ubuntu-latest + steps: + - name: Run Release Please + id: rp + uses: googleapis/release-please-action@5c625bfb5d1ff62eadeeb3772007f7f66fdcf071 # v4.4.1 + with: + config-file: .github/release-please-config.json + manifest-file: .github/release-please-manifest.json + + - name: Checkout + if: steps.rp.outputs.releases_created == 'true' + uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 + with: + fetch-depth: 0 + + - name: Fast-forward major/minor floats + if: steps.rp.outputs.releases_created == 'true' + env: + RP_OUTPUTS: ${{ toJSON(steps.rp.outputs) }} + run: | + set -euo pipefail + git config user.name "github-actions[bot]" + git config user.email "41898282+github-actions[bot]@users.noreply.github.com" + echo "$RP_OUTPUTS" | jq -r ' + (.paths_released | fromjson) as $paths + | $paths[] as $p + | "\(.[$p + "--tag_name"])\t\(.[$p + "--sha"])" + ' | while IFS=$'\t' read -r TAG SHA; do + COMP="${TAG%/*}" + VER="${TAG##*/v}" + MAJ="${VER%%.*}" + REST="${VER#*.}" + MIN="${REST%%.*}" + echo "Fast-forwarding ${COMP}/v${MAJ} and ${COMP}/v${MAJ}.${MIN} -> ${SHA}" + git tag -f "${COMP}/v${MAJ}" "${SHA}" + git tag -f "${COMP}/v${MAJ}.${MIN}" "${SHA}" + git push origin -f "${COMP}/v${MAJ}" "${COMP}/v${MAJ}.${MIN}" + done From 9f2d2145263fd5adc560897fdad1350d8f2c5549 Mon Sep 17 00:00:00 2001 From: PPawlowski Date: Wed, 22 Apr 2026 11:45:07 +0200 Subject: [PATCH 2/8] Remove autotag workflow --- .github/workflows/autotag.yml | 28 ---------------------------- 1 file changed, 28 deletions(-) delete mode 100644 .github/workflows/autotag.yml diff --git a/.github/workflows/autotag.yml b/.github/workflows/autotag.yml deleted file mode 100644 index 997d158..0000000 --- a/.github/workflows/autotag.yml +++ /dev/null @@ -1,28 +0,0 @@ -name: Bump reusable workflows version -on: - pull_request: - types: - - closed - branches: - - main - workflow_dispatch: - -jobs: - bump-version: - name: Bump version - if: github.event.pull_request.merged == true - runs-on: ubuntu-latest - permissions: - contents: write - steps: - - name: Checkout the code - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 - with: - ref: ${{ github.event.pull_request.merge_commit_sha }} - fetch-depth: '0' - - - name: Bump version and push tag - uses: anothrNick/github-tag-action@4ed44965e0db8dab2b466a16da04aec3cc312fd8 # 1.75.0 - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - WITH_V: true From b226c00fc46e435a091ee92a0a8a9e948a7f1887 Mon Sep 17 00:00:00 2001 From: PPawlowski Date: Wed, 22 Apr 2026 11:45:26 +0200 Subject: [PATCH 3/8] Ensure dependabot PRs follows conventional commit pattern --- .github/dependabot.yml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 1ef2d0c..d4899ef 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -5,3 +5,6 @@ updates: schedule: interval: "weekly" open-pull-requests-limit: 25 + commit-message: + prefix: "chore" + include: "scope" From 1378ad89c12a63ddeb76d390be15af2387ab5448 Mon Sep 17 00:00:00 2001 From: PPawlowski Date: Wed, 22 Apr 2026 11:45:48 +0200 Subject: [PATCH 4/8] Add "Lint Pull Request Title" workflow --- .github/workflows/lint-pr-title.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 .github/workflows/lint-pr-title.yaml diff --git a/.github/workflows/lint-pr-title.yaml b/.github/workflows/lint-pr-title.yaml new file mode 100644 index 0000000..ccc444d --- /dev/null +++ b/.github/workflows/lint-pr-title.yaml @@ -0,0 +1,16 @@ +name: Lint Pull Request Title + +on: + pull_request: + types: [opened, edited, synchronize, reopened] + +permissions: + pull-requests: read + +jobs: + lint: + runs-on: ubuntu-latest + steps: + - uses: amannn/action-semantic-pull-request@48f256284bd46cdaab1048c3721360e808335d50 # v6.1.1 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} From bb1b7a9107ff55d7ea2c56685e612fd68e25c27d Mon Sep 17 00:00:00 2001 From: PPawlowski Date: Wed, 22 Apr 2026 11:46:24 +0200 Subject: [PATCH 5/8] Add initial changelog file --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 CHANGELOG.md diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..825c32f --- /dev/null +++ b/CHANGELOG.md @@ -0,0 +1 @@ +# Changelog From 48c4b0bf46aeca2389063f7fdc6337d2bfeebeb7 Mon Sep 17 00:00:00 2001 From: PPawlowski Date: Wed, 22 Apr 2026 14:18:01 +0200 Subject: [PATCH 6/8] Document the release process --- README.md | 108 +++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 107 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index c110be8..2cf8fe4 100644 --- a/README.md +++ b/README.md @@ -1 +1,107 @@ -General purpose reusable Github Action workflows +# github-actions-workflows + +General purpose reusable GitHub Action workflows and composite actions. + +## Versioning and Release Process + +Each reusable workflow and composite action in this repository is versioned and +released **independently** using [Release Please](https://github.com/googleapis/release-please). +The next version of each component is determined automatically from the +[Conventional Commits](https://www.conventionalcommits.org/) in pull request +titles that touched the component's files. + +### Components + +1. The `Prepare release` GitHub Action workflow + (`.github/workflows/release-please.yaml`): + + * Runs `release-please-action` on every push to `main`. Release Please + analyzes commit messages since the last release and groups pending + version bumps into a single, rolling release pull request. + * The release PR lists one entry per component that has unreleased + changes, each with its proposed new version and changelog excerpt. + * Merging the release PR creates the exact version tag for each + released component (e.g. `build_container_image/v1.2.3`) and writes + the aggregated entries into the repo-root `CHANGELOG.md`. + * After the exact tags are created, the same workflow fast-forwards + the per-component **floating tags** - the major float + `/vX` and the minor float `/vX.Y` - so they + point at the same commit. Consumers pinned to a float automatically + pick up the new release on their next run. + +2. The `Lint Pull Request Title` GitHub Action workflow + (`.github/workflows/lint-pr-title.yaml`): + + * Runs on every pull request and uses the + `amannn/action-semantic-pull-request` action to validate that the + pull request title follows the Conventional Commits format. + * This repository squash-merges all pull requests, so the PR title + becomes the squash commit's subject line. The lint gate therefore + ensures that Release Please can parse every commit merged into + `main`. + +### Pull Request Title Format + +The Conventional Commits preset expects pull request titles to be in the +following format: + + (): + +* Type: Describes the category of the commit. Examples include: + * `feat`: A new feature (triggers a minor version bump). + * `fix`: A bug fix (triggers a patch version bump). + * `perf`: A code change that improves performance (triggers a patch + version bump). + * `refactor`: A code change that neither fixes a bug nor adds a + feature (triggers a patch version bump unless it is a + BREAKING CHANGE). + * `docs`: Documentation-only changes. + * `chore`: Routine maintenance (e.g. CI tweaks, dependency bumps). +* Scope: An optional part that provides additional context about what + was changed (e.g. module, component). +* Subject: A brief description of the changes. + +A commit whose files fall within a component's tracked paths always +produces at least a patch bump for that component, regardless of type. +Types like `chore` and `docs` are hidden from the visible `CHANGELOG.md` +but still participate in version calculation. + +### Handling Breaking Changes + +To indicate a breaking change, the exclamation mark `!` should be used +immediately after the type (or type and scope): + +* `feat!:` +* `fix!:` +* `refactor!:` + +A breaking commit bumps the affected components to a new major version. +Consumers pinned to the previous major float (e.g. +`@build_container_image/v1`) stay frozen on the old major line — picking +up the new major requires re-pinning to the new float explicitly. + +### Tag Scheme + +For every release, three tags are produced per affected component: + +| Tag | Mutability | Points at | +|------------------------|-------------------------------------|-----------------------------------| +| `/vX.Y.Z` | immutable | The release commit | +| `/vX.Y` | moves on patch releases | Latest patch of `vX.Y.x` | +| `/vX` | moves on any non-breaking release | Latest non-breaking of `vX.x.y` | + +Consumers reference a component by one of these tags: + +```yaml +# Major float — auto-updates on every non-breaking release (recommended): +uses: FlowFuse/github-actions-workflows/.github/workflows/build_container_image.yml@build_container_image/v1 + +# Minor float — auto-updates only on patches: +uses: FlowFuse/github-actions-workflows/.github/workflows/build_container_image.yml@build_container_image/v1.2 + +# Exact pin — never moves: +uses: FlowFuse/github-actions-workflows/.github/workflows/build_container_image.yml@build_container_image/v1.2.3 + +# Composite actions use the same pattern: +uses: FlowFuse/github-actions-workflows/actions/npm_test@npm_test/v1 +``` From 16d244ec2cd7043a89de7e0d888eb492378fca06 Mon Sep 17 00:00:00 2001 From: PPawlowski Date: Thu, 23 Apr 2026 14:19:04 +0200 Subject: [PATCH 7/8] Document process of adding new workflow/action to the release flow --- README.md | 74 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/README.md b/README.md index 2cf8fe4..49ac985 100644 --- a/README.md +++ b/README.md @@ -105,3 +105,77 @@ uses: FlowFuse/github-actions-workflows/.github/workflows/build_container_image. # Composite actions use the same pattern: uses: FlowFuse/github-actions-workflows/actions/npm_test@npm_test/v1 ``` + +### Adding a New Reusable Workflow or Composite Action + +When introducing a new component, it must be registered with Release Please +so that it is versioned and tagged independently like the existing ones. + +1. **Create the workflow or action file.** + + * Reusable workflow: place the YAML file at + `.github/workflows/.yml`. + * Composite action: create the directory `actions//` and add its + `action.yml` (plus any supporting files). + * `` must be unique across **all** workflows and actions — the + two share a flat tag namespace. + +2. **Register the component in `.github/release-please-config.json`** + by adding a new entry under `packages`. + + * For a reusable workflow: + + ```json + ".github/workflows/": { + "component": "", + "include-paths": [".github/workflows/.yml"] + } + ``` + + The package key is a virtual path (no directory is created on + disk); `include-paths` scopes change detection to the single YAML + file. + + * For a composite action: + + ```json + "actions/": { + "component": "" + } + ``` + + The package key is the action's real directory; `include-paths` is + not needed because any file under that directory is attributed to + the component. + +3. **Seed the initial version in `.github/release-please-manifest.json`** + using the same key chosen in the previous step: + + ```json + "": "1.0.0" + ``` + +4. **Open the pull request with a Conventional Commit title**, for + example `feat: add reusable workflow`. + +5. **After merging the pull request, bootstrap the initial tags** for + the new component. They must exist before consumers can reference it + and before Release Please runs cleanly for the new entry: + + ```bash + git fetch origin main + SHA=$(git rev-parse origin/main) + NAME="" + git tag "${NAME}/v1.0.0" "${SHA}" + git tag "${NAME}/v1.0" "${SHA}" + git tag "${NAME}/v1" "${SHA}" + git push origin "${NAME}/v1.0.0" "${NAME}/v1.0" "${NAME}/v1" + ``` + + > If Release Please happens to run between the merge and this + > bootstrap (it triggers on every push to `main`), it may open a + > stray release pull request proposing an inflated first version for + > the new component, because it has no tag to use as a baseline. + > Simply close that pull request — the next Release Please run, once + > the bootstrap tags exist, will be a no-op for the new component. + From 15df5ccf5a57657f3b531b0fdfeef3d5c28b112d Mon Sep 17 00:00:00 2001 From: PPawlowski Date: Thu, 23 Apr 2026 14:28:36 +0200 Subject: [PATCH 8/8] Fix readme --- README.md | 111 +++++++++++++++--------------------------------------- 1 file changed, 30 insertions(+), 81 deletions(-) diff --git a/README.md b/README.md index 49ac985..e364928 100644 --- a/README.md +++ b/README.md @@ -4,81 +4,49 @@ General purpose reusable GitHub Action workflows and composite actions. ## Versioning and Release Process -Each reusable workflow and composite action in this repository is versioned and -released **independently** using [Release Please](https://github.com/googleapis/release-please). -The next version of each component is determined automatically from the -[Conventional Commits](https://www.conventionalcommits.org/) in pull request -titles that touched the component's files. +Each reusable workflow and composite action in this repository is versioned and released **independently** using [Release Please](https://github.com/googleapis/release-please). The next version of each component is determined automatically from the [Conventional Commits](https://www.conventionalcommits.org/) in pull request titles that touched the component's files. ### Components -1. The `Prepare release` GitHub Action workflow - (`.github/workflows/release-please.yaml`): - - * Runs `release-please-action` on every push to `main`. Release Please - analyzes commit messages since the last release and groups pending - version bumps into a single, rolling release pull request. - * The release PR lists one entry per component that has unreleased - changes, each with its proposed new version and changelog excerpt. - * Merging the release PR creates the exact version tag for each - released component (e.g. `build_container_image/v1.2.3`) and writes - the aggregated entries into the repo-root `CHANGELOG.md`. - * After the exact tags are created, the same workflow fast-forwards - the per-component **floating tags** - the major float - `/vX` and the minor float `/vX.Y` - so they - point at the same commit. Consumers pinned to a float automatically - pick up the new release on their next run. - -2. The `Lint Pull Request Title` GitHub Action workflow - (`.github/workflows/lint-pr-title.yaml`): - - * Runs on every pull request and uses the - `amannn/action-semantic-pull-request` action to validate that the - pull request title follows the Conventional Commits format. - * This repository squash-merges all pull requests, so the PR title - becomes the squash commit's subject line. The lint gate therefore - ensures that Release Please can parse every commit merged into - `main`. +1. The `Prepare release` GitHub Action workflow (`.github/workflows/release-please.yaml`): + + * Runs `release-please-action` on every push to `main`. Release Please analyzes commit messages since the last release and groups pending version bumps into a single, rolling release pull request. + * The release PR lists one entry per component that has unreleased changes, each with its proposed new version and changelog excerpt. + * Merging the release PR creates the exact version tag for each released component (e.g. `build_container_image/v1.2.3`) and writes the aggregated entries into the repo-root `CHANGELOG.md`. + * After the exact tags are created, the same workflow fast-forwards the per-component **floating tags** - the major float `/vX` and the minor float `/vX.Y` - so they point at the same commit. Consumers pinned to a float automatically pick up the new release on their next run. + +2. The `Lint Pull Request Title` GitHub Action workflow (`.github/workflows/lint-pr-title.yaml`): + + * Runs on every pull request and uses the `amannn/action-semantic-pull-request` action to validate that the pull request title follows the Conventional Commits format. + * This repository squash-merges all pull requests, so the PR title becomes the squash commit's subject line. The lint gate therefore ensures that Release Please can parse every commit merged into `main`. ### Pull Request Title Format -The Conventional Commits preset expects pull request titles to be in the -following format: +The Conventional Commits preset expects pull request titles to be in the following format: (): * Type: Describes the category of the commit. Examples include: * `feat`: A new feature (triggers a minor version bump). * `fix`: A bug fix (triggers a patch version bump). - * `perf`: A code change that improves performance (triggers a patch - version bump). - * `refactor`: A code change that neither fixes a bug nor adds a - feature (triggers a patch version bump unless it is a - BREAKING CHANGE). + * `perf`: A code change that improves performance (triggers a patch version bump). + * `refactor`: A code change that neither fixes a bug nor adds a feature (triggers a patch version bump unless it is a BREAKING CHANGE). * `docs`: Documentation-only changes. * `chore`: Routine maintenance (e.g. CI tweaks, dependency bumps). -* Scope: An optional part that provides additional context about what - was changed (e.g. module, component). +* Scope: An optional part that provides additional context about what was changed (e.g. module, component). * Subject: A brief description of the changes. -A commit whose files fall within a component's tracked paths always -produces at least a patch bump for that component, regardless of type. -Types like `chore` and `docs` are hidden from the visible `CHANGELOG.md` -but still participate in version calculation. +A commit whose files fall within a component's tracked paths always produces at least a patch bump for that component, regardless of type. Types like `chore` and `docs` are hidden from the visible `CHANGELOG.md` but still participate in version calculation. ### Handling Breaking Changes -To indicate a breaking change, the exclamation mark `!` should be used -immediately after the type (or type and scope): +To indicate a breaking change, the exclamation mark `!` should be used immediately after the type (or type and scope): * `feat!:` * `fix!:` * `refactor!:` -A breaking commit bumps the affected components to a new major version. -Consumers pinned to the previous major float (e.g. -`@build_container_image/v1`) stay frozen on the old major line — picking -up the new major requires re-pinning to the new float explicitly. +A breaking commit bumps the affected components to a new major version. Consumers pinned to the previous major float (e.g. `@build_container_image/v1`) stay frozen on the old major line — picking up the new major requires re-pinning to the new float explicitly. ### Tag Scheme @@ -108,20 +76,15 @@ uses: FlowFuse/github-actions-workflows/actions/npm_test@npm_test/v1 ### Adding a New Reusable Workflow or Composite Action -When introducing a new component, it must be registered with Release Please -so that it is versioned and tagged independently like the existing ones. +When introducing a new component, it must be registered with Release Please so that it is versioned and tagged independently like the existing ones. 1. **Create the workflow or action file.** - * Reusable workflow: place the YAML file at - `.github/workflows/.yml`. - * Composite action: create the directory `actions//` and add its - `action.yml` (plus any supporting files). - * `` must be unique across **all** workflows and actions — the - two share a flat tag namespace. + * Reusable workflow: place the YAML file at `.github/workflows/.yml`. + * Composite action: create the directory `actions//` and add its `action.yml` (plus any supporting files). + * `` must be unique across **all** workflows and actions — the two share a flat tag namespace. -2. **Register the component in `.github/release-please-config.json`** - by adding a new entry under `packages`. +2. **Register the component in `.github/release-please-config.json`** by adding a new entry under `packages`. * For a reusable workflow: @@ -132,9 +95,7 @@ so that it is versioned and tagged independently like the existing ones. } ``` - The package key is a virtual path (no directory is created on - disk); `include-paths` scopes change detection to the single YAML - file. + The package key is a virtual path (no directory is created on disk); `include-paths` scopes change detection to the single YAML file. * For a composite action: @@ -144,23 +105,17 @@ so that it is versioned and tagged independently like the existing ones. } ``` - The package key is the action's real directory; `include-paths` is - not needed because any file under that directory is attributed to - the component. + The package key is the action's real directory; `include-paths` is not needed because any file under that directory is attributed to the component. -3. **Seed the initial version in `.github/release-please-manifest.json`** - using the same key chosen in the previous step: +3. **Seed the initial version in `.github/release-please-manifest.json`** using the same key chosen in the previous step: ```json "": "1.0.0" ``` -4. **Open the pull request with a Conventional Commit title**, for - example `feat: add reusable workflow`. +4. **Open the pull request with a Conventional Commit title**, for example `feat: add reusable workflow`. -5. **After merging the pull request, bootstrap the initial tags** for - the new component. They must exist before consumers can reference it - and before Release Please runs cleanly for the new entry: +5. **After merging the pull request, bootstrap the initial tags** for the new component. They must exist before consumers can reference it and before Release Please runs cleanly for the new entry: ```bash git fetch origin main @@ -172,10 +127,4 @@ so that it is versioned and tagged independently like the existing ones. git push origin "${NAME}/v1.0.0" "${NAME}/v1.0" "${NAME}/v1" ``` - > If Release Please happens to run between the merge and this - > bootstrap (it triggers on every push to `main`), it may open a - > stray release pull request proposing an inflated first version for - > the new component, because it has no tag to use as a baseline. - > Simply close that pull request — the next Release Please run, once - > the bootstrap tags exist, will be a no-op for the new component. - + > If Release Please happens to run between the merge and this bootstrap (it triggers on every push to `main`), it may open a stray release pull request proposing an inflated first version for the new component, because it has no tag to use as a baseline. Simply close that pull request — the next Release Please run, once the bootstrap tags exist, will be a no-op for the new component.