chore(main): release hve-core 3.0.0#547
Closed
hve-core-release-please[bot] wants to merge 1 commit intomainfrom
Closed
chore(main): release hve-core 3.0.0#547hve-core-release-please[bot] wants to merge 1 commit intomainfrom
hve-core-release-please[bot] wants to merge 1 commit intomainfrom
Conversation
hve-core-release-please
bot
added
the
autorelease: pending
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #547 +/- ##
==========================================
- Coverage 85.36% 85.34% -0.03%
==========================================
Files 23 23
Lines 4475 4475
==========================================
- Hits 3820 3819 -1
- Misses 655 656 +1
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
28 tasks
WilliamBerryiii
added a commit
that referenced
this pull request
Feb 13, 2026
… conversion (#545) ## Description Fixes a race condition where release-please `"draft": true` configuration caused draft releases that are excluded from the GitHub Releases API "latest" query, making them invisible to release-please's own version anchoring within the same workflow invocation. Because the draft release is invisible, release-please scans the full commit history, finds an old breaking change (PR #277), and proposes erroneous v3.0.0 major version bumps. Also added auto-detection of version from the latest GitHub release tag in both extension publish workflows, removing the requirement for manual version input on every dispatch. **Proof the race condition fires in production:** after v2.3.4 merged, release-please created the v2.3.4 release as draft at 22:05:23 UTC. At 22:08:14 UTC — while v2.3.4 was still draft — release-please opened PR #547 proposing v3.0.0. The v2.3.4 release was not published until 22:10:08 UTC, confirming that release-please computed the next version while v2.3.4 was invisible to its own Releases API query. Additionally, v2.3.2 remains stuck in draft state, demonstrating that the `publish-release` job's `gh release edit --draft=false` is unreliable when it depends on upstream jobs that may not always run. ### Changes - fix(workflows): removed `"draft": true` from root and package level in `release-please-config.json` so release-please creates published releases that are immediately visible to the Releases API for version anchoring - fix(workflows): removed `"force-tag-creation": true` from `release-please-config.json` since it requires release-please v17.2.0+ and was silently ignored by the bundled v17.1.3 - fix(workflows): replaced 20-line tag bridge step in `main.yml` with a `gh release edit --draft=true` post-creation conversion, allowing assets to be uploaded to a mutable draft release while preserving release visibility for version anchoring - feat(workflows): added auto-detection of version from latest GitHub release tag in `extension-publish-prerelease.yml` when version input is empty, with ODD minor derivation for the pre-release channel - feat(workflows): added auto-detection of version from latest GitHub release tag in `extension-publish.yml` when version input is empty, with `hve-core-v` prefix stripping - fix(workflows): updated `extension-publish.yml` input description to match new auto-detect behavior (was incorrectly referencing `package.json`) ## Related Issue(s) Fixes #543 ## Type of Change Select all that apply: **Code & Documentation:** - [x] Bug fix (non-breaking change fixing an issue) - [ ] New feature (non-breaking change adding functionality) - [ ] Breaking change (fix or feature causing existing functionality to change) - [ ] Documentation update **Infrastructure & Configuration:** - [x] GitHub Actions workflow - [ ] Linting configuration (markdown, PowerShell, etc.) - [ ] Security configuration - [ ] DevContainer configuration - [ ] Dependency update **AI Artifacts:** - [ ] Reviewed contribution with `prompt-builder` agent and addressed all feedback - [ ] Copilot instructions (`.github/instructions/*.instructions.md`) - [ ] Copilot prompt (`.github/prompts/*.prompt.md`) - [ ] Copilot agent (`.github/agents/*.agent.md`) - [ ] Copilot skill (`.github/skills/*/SKILL.md`) **Other:** - [ ] Script/automation (`.ps1`, `.sh`, `.py`) - [ ] Other (please describe): ## Testing - Validated YAML linting passes via `npm run lint:yaml` — all 25 workflow files passed - Verified `release-please-config.json` is valid JSON with no schema errors - Confirmed the `publish-release` job already contains `gh release edit --draft=false` to finalize releases after asset upload - Confirmed `gh release view --json tagName` correctly returns the latest release tag format (`hve-core-v2.3.4`) ## Checklist ### Required Checks - [x] Documentation is updated (if applicable) - [x] Files follow existing naming conventions - [x] Changes are backwards compatible (if applicable) - [ ] Tests added for new functionality (if applicable) ### Required Automated Checks The following validation commands must pass before merging: - [x] Markdown linting: `npm run lint:md` - [ ] Spell checking: `npm run spell-check` - [ ] Frontmatter validation: `npm run lint:frontmatter` - [ ] Link validation: `npm run lint:md-links` - [ ] PowerShell analysis: `npm run lint:ps` ## Security Considerations - [x] This PR does not contain any sensitive or NDA information - [ ] Any new dependencies have been reviewed for security issues - [x] Security-related scripts follow the principle of least privilege ## Additional Notes The release lifecycle after this change follows a four-phase sequence: release-please creates a **published** release (tag created, visible to Releases API) → post-creation step converts to **draft** (mutable for asset upload) → package/attest/upload jobs attach assets → `publish-release` job converts back to **published**. This preserves the original HTTP 422 fix from PR #538 while eliminating the version anchoring race condition that caused PRs #530, #532, #534, #539, #540, #542, and #547. ### Why the tag bridge didn't work The tag bridge step from PR #538 manually created git tags after draft release creation. However, release-please anchors its version calculation on the GitHub **Releases** API (not the Tags API). Even though tag `hve-core-v2.3.4` existed at commit `9a72f2b`, release-please's query for the latest release excluded the draft, causing it to scan the full commit history and hit the old breaking change from PR #277.
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
3.0.0 (2026-02-13)
⚠ BREAKING CHANGES
✨ Features
🐛 Bug Fixes
📚 Documentation
♻️ Refactoring
🔧 Maintenance
This PR was generated with Release Please. See documentation.