Skip to content

Bump v1 to 1.1.7 and scope external-release pipeline to release/v1#1792

Merged
badrishc merged 1 commit into
release/v1from
badrishc/release-v1
May 12, 2026
Merged

Bump v1 to 1.1.7 and scope external-release pipeline to release/v1#1792
badrishc merged 1 commit into
release/v1from
badrishc/release-v1

Conversation

@badrishc

Copy link
Copy Markdown
Collaborator

Summary

Cuts a v1 patch release (1.1.7) and rewires .azure/pipelines/azure-pipelines-external-release.yml so the release/v1 copy of that pipeline drives v1 releases, while the main copy continues to drive v2/preview releases from main and dev.

Changes

  • Version.props: VersionPrefix 1.1.6 → 1.1.7
  • .azure/pipelines/azure-pipelines-external-release.yml (release/v1 copy only):
    • Header note: "branch that isn't main" → "branch that isn't release/v1"
    • trigger.branches.include: mainrelease/v1
    • resources.repositories.self.ref: refs/heads/mainrefs/heads/release/v1
    • GitHubRelease@1 condition: eq(Build.SourceBranchName,'main')eq(Build.SourceBranch,'refs/heads/release/v1')
    • NuGetCommand@2 condition: same change
    • Switched from Build.SourceBranchName to Build.SourceBranch because SourceBranchName is just the leaf segment (v1 for refs/heads/release/v1), which is ambiguous.

Release behavior after merge

Merging this PR pushes a Version.props change onto release/v1, which:

  1. Triggers the external-release ADO pipeline (the release/v1 copy of the YAML).
  2. Builds, signs, and packs Garnet at version 1.1.7.
  3. Creates GitHub Release Garnet v1.1.7 (tag v1.1.7).
  4. Pushes Microsoft.Garnet.1.1.7.nupkg and garnet-server.1.1.7.nupkg to NuGet.org.

The main branch's pipeline is unchanged and unaffected.

ADO checks (out-of-band, not in this PR)

  • Confirm the ADO pipeline's Triggers UI does not "Override the YAML continuous integration trigger from here" (or, if it does, that release/v1 is in the included branches).
  • If you want manual / proof-of-presence runs to default to release/v1, either change the pipeline's default branch or clone the pipeline definition for the v1 line.
  • Confirm ADO_to_Github_ServiceConnection, GarnetCodeSignConn, and GarnetADO_to_Nuget are authorized for the pipeline with no branch restriction limiting them to main.

- Version.props: 1.1.6 -> 1.1.7
- azure-pipelines-external-release.yml: trigger and self ref now
  point at release/v1; GitHubRelease/NuGet push conditions check
  Build.SourceBranch == refs/heads/release/v1.

The main branch's copy of the pipeline is unchanged and continues
to drive v2 / preview releases from main and dev.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings May 12, 2026 19:08

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR prepares the v1 line for a patch release (v1.1.7) and updates the external release Azure Pipelines YAML (in the release/v1 branch) so that release automation is scoped specifically to release/v1 rather than main.

Changes:

  • Bump VersionPrefix from 1.1.6 to 1.1.7.
  • Update the external-release pipeline trigger and repository ref to release/v1.
  • Update GitHub Release and NuGet push gating conditions to check Build.SourceBranch against refs/heads/release/v1.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
Version.props Increments the v1 patch version to 1.1.7.
.azure/pipelines/azure-pipelines-external-release.yml Scopes external release trigger/ref/conditions to release/v1 and updates header note accordingly.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines 2 to 5
# NOTE: Before running this pipeline to generate a the GitHub Release and new nuget packages, update the VersionPrefix value in Version.props file
# NOTE: When Version.props file is modified, this pipeline will automatically get triggered
# NOTE: If this pipeline is ran against a branch that isn't main, the GitHub Release task and NuGet push task will be skipped
# NOTE: If this pipeline is ran against a branch that isn't release/v1, the GitHub Release task and NuGet push task will be skipped
# NOTE: If this pipeline is manually started, a "Proof of Presence" (from a SAW machine) will be required before this pipeline can proceed.
Comment on lines 14 to +18
resources:
repositories:
- repository: self
type: git
ref: refs/heads/main
ref: refs/heads/release/v1
@badrishc badrishc merged commit 53137e2 into release/v1 May 12, 2026
5 checks passed
@badrishc badrishc deleted the badrishc/release-v1 branch May 12, 2026 19:21
Mathos1432 added a commit that referenced this pull request May 14, 2026
release/v1 just bumped to 1.1.7 in #1792. Bump again to 1.1.8 as part of this PR so the package built from this branch sorts above the latest published version.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
badrishc pushed a commit that referenced this pull request May 15, 2026
… and dispose race in AofSyncTaskInfo (#1791)

* Fix GarnetClientSession leak and diskless replication dedup failure

Two related bugs in AofTaskStore caused unbounded accumulation
of AofSyncTaskInfo tasks on clusters using diskless replication.

1. TryAddReplicationTasks (the diskless path) compared existing
   tasks against rss.replicaNodeId for dedup. ReplicaSyncSession
   has two node ID fields: replicaNodeId (set by the disk-based
   constructor, null for diskless) and replicaSyncMetadata.originNodeId
   (set by the diskless constructor). The AofSyncTaskInfo was
   created with originNodeId, but dedup compared against the null
   replicaNodeId — so it never matched and every call added a new
   task. Over time numTasks grew unboundedly, inflating the
   RoleInfo[] from INFO REPLICATION until the response exceeded
   the network output buffer.

   Fix: use rss.replicaSyncMetadata.originNodeId in the dedup
   comparison. The singular TryAddReplicationTask (disk-based
   and CLUSTER AOFSYNC) is unaffected.

2. AofSyncTaskInfo.Dispose() did not dispose its owned
   GarnetClientSession. When ReplicaSyncTaskAsync is running,
   CTS cancellation causes it to exit and the finally block
   cleans up. But when ReplicaSyncTaskAsync has not yet started
   (e.g. the task fails to be added), Dispose() is the only
   cleanup path and the session was leaked.

   Fix: add garnetClient?.Dispose() to AofSyncTaskInfo.Dispose()
   and remove the redundant call from ReplicaSyncTaskAsync's
   finally block, giving a single disposal site.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* AofSyncTaskInfo termination log fix

Clarify that the client disposal is no longer happening in the finally block.

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

* Fix formatting issues from CI

* Add Allure attributes to AofSyncTaskInfoTests

Apply [AllureNUnit] attribute and inherit AllureTestBase to
match repo test conventions required by CI.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Add REPLICATION category to AofSyncTaskInfoTests

Categorize the test to match the existing replication test
convention in the cluster test project.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Backport ActiveWorkerMonitor

* Address review feedback: drain in-flight workers, defensive Dispose, idempotency

- Use ActiveWorkerMonitor (backported from PR #1556) to drain in-flight ReplicaSyncTaskAsync before disposing GarnetClientSession, eliminating cross-thread dispose races against ExecuteClusterAppendLog.
- Defensively call Dispose() in ReplicaSyncTaskAsync's finally when TryRemove returns false, guarding against future removal sites that forget to dispose.
- Make AofSyncTaskInfo.Dispose() idempotent (Interlocked guard) so multiple disposal sites cannot trigger ObjectDisposedException from cts.Cancel after cts.Dispose.
- Drop the unreachable enteredMonitor flag; control only enters the try block when TryEnter succeeded.
- Test: extend DisposeReleasesGarnetClientSession to assert idempotency.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Bump version to 1.1.6.2 and surface Revision in startup log

Version.props now declares 1.1.6.2 (was 1.1.6) so that nuget packages produced from this branch carry the patch identifier.

GarnetServer.GetVersion() previously returned only Major.Minor.Build, which caused 1.1.6.2 builds to log themselves as 1.1.6 at startup. Append the Revision when non-zero so the startup log matches the assembly version.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Revert "Bump version to 1.1.6.2 and surface Revision in startup log"

This reverts commit 54cbd42. The version bump and the GetVersion() Revision-aware formatting are out of scope for this PR; the version bump should land on its own.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Bump version from 1.1.7 to 1.1.8

release/v1 just bumped to 1.1.7 in #1792. Bump again to 1.1.8 as part of this PR so the package built from this branch sorts above the latest published version.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* retrigger CI

* trigger CI

---------

Co-authored-by: Simon Nattress <simonn@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Simon Nattress <nattress@gmail.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Vasileios Zois <vazois@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants