Repository navigation
fix(hidi): track independent versions with standard release-please components - #897
Merged
Gavin Barron (gavinbarron) merged 4 commits intoOct 9, 2026
Conversation
Apply exact-file release routing through the pinned release-please plugin API. Keep OData releases unchanged and maintain isolated Hidi version PR checkpoints without creating production tags or releases. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5aef9099-c268-492f-a58a-b591c916f1bc
Create only the two verified Hidi lifecycle labels, retain tag-free version cycles after baseline advances, and retire the duplicate unfiltered OData tag writer and its GitHub-release-only consumer. Keep official publishing gates unchanged. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5aef9099-c268-492f-a58a-b591c916f1bc
Follow the supplied migration reference with two packages and versions in one config and manifest. Retain separate-pull-requests only as the stock-engine compatibility setting for OData componentless tags; restore accepted workflows and remove the superseded custom runner and duplicated Hidi release scaffolding. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5aef9099-c268-492f-a58a-b591c916f1bc
Gavin Barron (gavinbarron)
changed the title
Restrict main OData releases to v3 tags and dedicated Hidi releases to hidi-v3 tags. Validate tag/project versions before staging, use supported OData-only pack inputs with no rebuild, and select exact tag-version packages and assets. Preserve branch validation, Hidi publishing flags, signing and protected environments. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5aef9099-c268-492f-a58a-b591c916f1bc
|
Peter Ombwa (peombwa)
approved these changes
Oct 9, 2026
Gavin Barron (gavinbarron)
deleted the
gavinbarron-hidi-main-automated-versioning
branch
October 9, 2026 22:27
12 of 19 tasks
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.
Summary
Follow the user-provided standard multi-component reference
a65052d57fa5e623c765024fb05a0384691a9168and the subsequent request that ADO releases publish only the component selected by the triggering tag.Standard independent versions
.remains 3.2.1; Hidisrc/Microsoft.OpenApi.Hidiremains 3.10.2.hidi-v3.*tags; OData root changelog/Directory.Build.props updater and componentlessv*tags.separate-pull-requests: true, preserves OData-only componentless release parsing in the pinned engine.User-directed ADO component-tag routing
.azure-pipelines/ci-build.yml: tag triggerv3.*; deploy requiressucceeded()andstartsWith(Build.SourceBranch, 'refs/tags/v3.'). First build step rejects wrong/malformed tags and tag/Directory.Build.props mismatches before tooling/staging.DotNetCoreCLI@2pack inputs:packagesToPackselects only the OData project,configuration/packDirectory/nobuild/includesymbols/includesource/buildPropertiesare the supported pack contract. The oldprojects/argumentswere ignored for pack, risking all-project packaging and a post-signing rebuild..azure-pipelines/hidi-release.yml: retainshidi-v3.*trigger and flag-gated matching publish condition. Move existing Hidi major/exact-tag/project check to the first build step. Require valid Hidi tag, preserved migration floor, exact package/symbols/executable/versioned ZIP, and matching container context project/tag version.Validation
Session-only actual stock release-please 17.6.0 plans and rendered XML/changelog/manifest/tag candidates pass 10 scenarios: Hidi fix
hidi-v3.10.3/ featurehidi-v3.11.0leave OData unchanged; OData fixv3.2.2/ featurev3.3.0leave Hidi unchanged; mixed source changes produce both candidates. Dependencies unchanged. Honest boundaries documented: Hidi tests outside its source package do not independently release Hidi; root distribution/helper files follow stock root routing.126 session-only checks parse the actual ADO YAML and execute its PowerShell guard/selector blocks: OData/Hidi tags, branch/PR/manual builds, unknown/other-major/malformed/case-mismatched tags, version mismatches, prereleases, ambiguous/wrong-version packages, missing Hidi assets, container mismatch and migration floor. Actual stage conditions and unchanged branch/PR filters/Hidi false flags are checked; all embedded PowerShell scripts parse.
Actual local OData-only
dotnet pack --no-buildproduces only Microsoft.OpenApi.OData.3.2.1.nupkg + .snupkg, matching nuspec identity/version. The DLL hash is unchanged before/after pack, proving no post-signing rebuild behavior. Stock workflow actionlint passes.Safety and landing
No actual release, tag, publishing run, label or resource grant created during validation. Hidi stable/preview publishing flags remain false. Protected environments, service connections, private-feed checks, signing contract and Hidi 3.10.2 migration floor remain unchanged; source version baselines and accepted Docker/ESRP history are preserved. This does not assert production signing/authorization readiness or resolve unrelated Sonar work.
Parent coordinates v2-first landing; no merge or auto-merge.