chore(main): release b24rabbitmq 0.1.0#20
Merged
IgorShevchik merged 2 commits intoMay 29, 2026
Conversation
IgorShevchik
pushed a commit
that referenced
this pull request
May 28, 2026
github-actions
Bot
force-pushed
the
release-please--branches--main--components--b24rabbitmq
branch
from
dd79771 to
ac00749
Compare
IgorShevchik
pushed a commit
that referenced
this pull request
May 29, 2026
Manual reconciliation between release-please's auto-generated [0.1.0] block (short subject lines from commits, plus 4 stale uuidv7/type-msg leftovers from pre-0.0.4 history) and the hand-written Unreleased block we maintained through PRs #10-#21 (rich per-entry descriptions with behavioural-change callouts). This is the one-shot reconciliation flagged in CONTRIBUTING.md "Release flow -> CHANGELOG reconciliation on the first auto- release" — subsequent releases will land cleanly because the hand-written approach ends with v0.1. Kept from release-please: - [0.1.0] heading with compare link and 2026-05-28 date. Replaced with hand-written content: - Added (3): release-please+OIDC #19/#21, TypeDoc #18, Logger DI #15. - Changed (3): types any->unknown #16, consumer reconnect #14, producer prefetch #13. - Removed (1): RabbitRPC dropped #12. - Bug Fixes (2): ack/nack idempotency #17, base/registerQueue merge #10. Dropped: - 4 stale `fix(uuidv7): improve` entries from pre-0.0.4 history (already covered in [0.0.3] / [0.0.2] sections below). - 1 stale `fix(type/Message): improve` (already in [0.0.4]). - 7 noise `docs: improve` / `docs(en): fix nav` entries from pre-reanimation that release-please surfaced without bootstrap-sha. Also captures PR #16 (chore(types)) + PR #19 / #21 (chore(release)) which release-please hides under the chore: hidden setting. The hand-written entries describe what actually shipped. Gates: lint, typecheck, test (66/66), build, docs:build all green. Note: this commit is pushed to the release-please branch (not main) — it amends release-please PR #20 in-place. The push from a non-GITHUB_TOKEN identity also triggers PR-time CI, which the original release-please-bot push could not because of GitHub's loop-prevention rule.
IgorShevchik
added a commit
that referenced
this pull request
May 29, 2026
…ck (#22) Branch protection on main was configured to require a status check named `ci`. GitHub reports check statuses per-job, not per-workflow, so the required check sat as "Expected — Waiting for status to be reported" forever, silently blocking every PR (including the release-please PR #20 for v0.1.0). Without admin access to edit branch protection, the cleanest workaround is to make the missing check exist: a tiny aggregator job named `ci` at the bottom of .github/workflows/ci.yml that `needs: [lint, typecheck, test, build, docs]` and reports success/failure based on their combined results. if: always() is load-bearing — without it a failed dependency causes the aggregator to be skipped, which leaves the required check perma-pending and reproduces the exact bug being fixed. `Commit messages` (commitlint) is intentionally excluded from needs: because it only runs on pull_request events and would mark the aggregator as failed on direct pushes to main. Branch protection can require Commit messages alongside ci, or require just ci and accept that commit discipline is enforced PR-side only. CONTRIBUTING.md "One-time maintainer setup" step #2 rewritten to document both options (single aggregator vs explicit list) with an explicit warning that adding the workflow filename (ci / ci.yml) instead of a job name silently blocks every PR. Verified working: this PR's own CI run produced a green `ci` status (8/8 checks including the new aggregator), which is exactly the path it needs to unblock PR #20 after rebase. Gates: lint, typecheck, test (66/66), build, docs:build all green. No src/ changes.
github-actions
Bot
force-pushed
the
release-please--branches--main--components--b24rabbitmq
branch
from
f27df8c to
822c00a
Compare
…e-push) Same reconciliation as commit 86312d4 — release-please bot force- pushed the release-please branch when PR #22 (ci aggregator) merged to main, wiping the earlier reconciliation. This commit restores it with the date refreshed to 2026-05-29. Manual reconciliation between release-please's auto-generated [0.1.0] block (short subject lines, plus stale uuidv7/type-msg leftovers from pre-0.0.4 history) and the hand-written Unreleased block we maintained through PRs #10-#21 (rich per-entry descriptions with behavioural-change callouts). The push from this identity (non-GITHUB_TOKEN) also triggers PR- time CI on PR #20 — which now includes the `ci` aggregator job that satisfies branch protection's required check (#22). Kept from release-please: [0.1.0] heading + compare link + date. Replaced body with hand-written rich content covering #10-#21, dropped 4 stale uuidv7 entries (already in [0.0.3]/[0.0.2]), 1 stale type/Message entry (already in [0.0.4]), and 7 noisy docs: improve entries from pre-reanimation. Gates: lint, test (66/66), docs:build all green.
Contributor
Author
|
🤖 Created releases: 🌻 |
IgorShevchik
pushed a commit
that referenced
this pull request
May 29, 2026
…de 24 opt-in Three small fixes bundled — all touch the release pipeline. 1. Tag mismatch in npm-publish (real blocker for v0.1 on npm): release-please created tag `b24rabbitmq-v0.1.0` (manifest-mode default — component prefix derived from package-name). The sanity check in npm-publish.yml stripped only `refs/tags/` + `v`, leaving `b24rabbitmq-v0.1.0` vs `0.1.0` in package.json -> mismatch -> publish fails with `::error::Tag b24rabbitmq-... does not match`. The release-please workflow run on PR #20's merge surfaced the publish failure. Fix: extract a `strip_tag()` shell helper that strips both `b24rabbitmq-` (legacy) and `v` (current convention). Same helper used on both the release-event path and the workflow_ dispatch fallback. Dry-tested locally for `b24rabbitmq-v0.1.0`, `v0.1.1`, `0.1.0`, and `b24rabbitmq-0.1.0` — all normalise to the bare semver. 2. Future tags should be plain `vX.Y.Z`: `include-component-in-tag: false` added to release-please- config.json. Single-package repo, the component prefix only added noise. Once this lands, the next release-please PR proposes tag `v0.1.1` (not `b24rabbitmq-v0.1.1`), and the shell strip helper still works for both formats. 3. Node 20 deprecation warning on release-please-action@v4: Workflow run https://github.com/bitrix24/b24rabbitmq/actions/runs/26621102915 surfaced the GitHub Actions runner deprecation notice for Node.js 20 (mandatory Node 24 from 2026-06-02). The action hasn't shipped a Node 24 native release yet. Opt the workflow into Node 24 via the documented FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true env var. Can be removed when the action bumps. Post-merge plan: - Re-trigger npm-publish.yml via workflow_dispatch on main (HEAD on main is the tagged commit `b24rabbitmq-v0.1.0`). - The strip helper accepts that tag -> 0.1.0 -> matches package.json -> OIDC publish proceeds. - After @bitrix24/b24rabbitmq@0.1.0 lands on npm, future releases will have plain `vX.Y.Z` tags and no manual workflow_dispatch will be needed. Gates: lint, typecheck, test (66/66), build, docs:build all green. No src/ changes.
IgorShevchik
pushed a commit
that referenced
this pull request
May 29, 2026
…de 24 opt-in (all workflows) Three small fixes bundled — all touch the release pipeline. 1. Tag mismatch in npm-publish (real blocker for v0.1 on npm): release-please created tag `b24rabbitmq-v0.1.0` (manifest-mode default — component prefix derived from package-name). The sanity check in npm-publish.yml stripped only `refs/tags/` + `v`, leaving `b24rabbitmq-v0.1.0` vs `0.1.0` in package.json -> mismatch -> publish fails with `::error::Tag b24rabbitmq-... does not match`. The release-please workflow run on PR #20's merge surfaced the publish failure. Fix: extract a `strip_tag()` shell helper that strips both `b24rabbitmq-` (legacy) and `v` (current convention). Same helper used on both the release-event path and the workflow_ dispatch fallback. Dry-tested locally for `b24rabbitmq-v0.1.0`, `v0.1.1`, `0.1.0`, and `b24rabbitmq-0.1.0` — all normalise to the bare semver. 2. Future tags should be plain `vX.Y.Z`: `include-component-in-tag: false` added to release-please- config.json. Single-package repo, the component prefix only added noise. Once this lands, the next release-please PR proposes tag `v0.1.1` (not `b24rabbitmq-v0.1.1`), and the shell strip helper still works for both formats. 3. Node 20 deprecation warning (all three workflows): Workflow run https://github.com/bitrix24/b24rabbitmq/actions/runs/26621102915 surfaced the GitHub Actions runner deprecation notice for Node.js 20 (mandatory Node 24 from 2026-06-02, removal 2026-09-16). googleapis/release-please-action@v4 was the one named in that run, but actions/checkout@v4, actions/setup-node@v4, and pnpm/action-setup@v4 are all JavaScript actions in the same bucket and surface the same warning across our other workflows. Fix: add `env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: 'true'` at the workflow level to all three workflows that run JS actions (release-please.yml, npm-publish.yml, ci.yml). Documented forward- compat flag from the runner deprecation notice. Single env var, no other behavioural change, removable once every action we pin has shipped a Node 24 native release. Post-merge plan: - Re-trigger npm-publish.yml via workflow_dispatch on main (HEAD on main is the tagged commit `b24rabbitmq-v0.1.0`). - The strip helper accepts that tag -> 0.1.0 -> matches package.json -> OIDC publish proceeds. - After @bitrix24/b24rabbitmq@0.1.0 lands on npm, future releases will have plain `vX.Y.Z` tags and no manual workflow_dispatch will be needed. Gates: lint, typecheck, test (66/66), build, docs:build all green. No src/ changes.
IgorShevchik
added a commit
that referenced
this pull request
May 29, 2026
…tag + Node 24 opt-in (#23) Three small interrelated fixes — all touch the release pipeline. No src/ changes. 1. Tag mismatch in npm-publish (real blocker for v0.1 on npm): release-please created tag `b24rabbitmq-v0.1.0` (manifest-mode default — component prefix derived from package-name). The sanity check in npm-publish.yml stripped only `refs/tags/` + `v`, leaving `b24rabbitmq-v0.1.0` vs `0.1.0` in package.json -> mismatch -> publish fails with `::error::Tag b24rabbitmq-... does not match`. The release-please workflow run on PR #20's merge surfaced the publish failure. Fix: extract a `strip_tag()` shell helper that strips both `b24rabbitmq-` (legacy) and `v` (current convention). Same helper used on both the release-event path and the workflow_dispatch fallback. Dry-tested locally for `b24rabbitmq-v0.1.0`, `v0.1.1`, `0.1.0`, and `b24rabbitmq-0.1.0` — all normalise to bare semver. 2. Future tags should be plain `vX.Y.Z`: `include-component-in-tag: false` added to release-please-config.json. Single-package repo, the component prefix only added noise. Once this lands, the next release-please PR proposes tag `v0.1.1`. 3. Node 20 deprecation warning (all three workflows): Workflow run https://github.com/bitrix24/b24rabbitmq/actions/runs/26621102915 surfaced the GitHub Actions runner deprecation notice for Node.js 20 (mandatory Node 24 from 2026-06-02, removal 2026-09-16). googleapis/release-please-action@v4 was named, but actions/checkout@v4, actions/setup-node@v4, and pnpm/action-setup@v4 are all JavaScript actions in the same bucket and surface the same warning across our other workflows. Fix: add `env: FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: 'true'` at the workflow level to release-please.yml, npm-publish.yml, and ci.yml. Documented forward-compat flag from the deprecation notice. Single env var, no other behavioural change, removable once every action ships a Node 24 native release. Post-merge: trigger npm-publish.yml via workflow_dispatch on main to ship @bitrix24/b24rabbitmq@0.1.0 via OIDC. Gates: lint, typecheck, test (66/66), build, docs:build, ci aggregator — all 8 green on PR #23.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
🤖 I have created a release beep boop
0.1.0 (2026-05-29)
Added
Bug Fixes
Changed
Documentation
This PR was generated with Release Please. See documentation.