Repository navigation
Release 0.11.3 - #189
Merged
Merged
Release 0.11.3#189
Conversation
arunav-gandhi
self-requested a review
October 21, 2026 08:55
manigandanparthasarathi-okta
approved these changes
Oct 21, 2026
manigandanparthasarathi-okta
added a commit
that referenced
this pull request
Oct 28, 2026
…NAPP-177 to NAPP-186) (#202) * NAPP-177: find the release PR even when the run starts right after the merge Same change as Guardian.swift#189, with the step kept identical on both SDKs. The 1.10.0 Release run on Guardian.swift started three seconds after the merge, before GitHub linked the merge commit to its PR, and skipped; the Android 0.11.3 run did not hit it, but the timing risk is the same. Detect release now reads the PR number from the squash title first (exact, and it settles ordinary merges at once), then falls back to the commit-to-PR lookup with 6 attempts 5 seconds apart. It also outputs the release PR number for the job summary. Co-Authored-By: Claude <noreply@anthropic.com> * NAPP-186: name the SDK and version in the approval request and summarise the release Same change as Guardian.swift#189. The deployment review email only said "Publish to Maven Central", so an approver could not tell what they were publishing. The publish job is now "Publish Guardian.Android X.Y.Z to Maven Central staging", which shows in the email, the run page and the approval dialog, and the supersede check matches it by prefix so runs named either way are still found. Validate version writes a job summary with the SDK, version, commit, release PR, a reminder that approval only uploads to staging, and the full CHANGELOG entry. Co-Authored-By: Claude <noreply@anthropic.com> * NAPP-183: clearer wording for the staging_dropped checkbox and its error The checkbox confused the team during the first runs. Its label in the Run workflow form is now "Replace an unpublished upload: tick only after you clicked Drop on this version's earlier upload in the Maven Central Portal", and the preflight error says exactly what to do: click Drop on that upload in Deployments, then run Release by hand with that box ticked, or release the next version if this one was already Published. A comment next to the input lists when to tick it and when not to. The input keeps its name, since the form shows the description, so behaviour and existing runbooks are unchanged. Co-Authored-By: Claude <noreply@anthropic.com> * NAPP-182: skip the Release Test job when the release PR already tested the same tree Same change as Guardian.swift#189, with the check step identical on both SDKs. For 0.11.3 the merge commit's tree was identical to the release PR head, whose Test check (lint, unit tests and the coverage gate) had just passed, so the Release Test job re-ran the same suite on the same files. Validate version now compares the trees and reads the PR head's latest Test check run; when the trees match and the check passed, the Test job is skipped, otherwise it runs as before. Publish accepts a skipped Test only in that case, and uses !cancelled() so a superseded run still stops. The approver summary says which way the tests were covered. Co-Authored-By: Claude <noreply@anthropic.com> * NAPP-179: move the build tooling to Ruby 3.3, in step with Guardian.swift fastlane warns that Ruby 3.2 support is going away and it will require 3.3, and Guardian.swift moved to 3.3 in #189, so .ruby-version moves from 3.2 to 3.3 (setup-ruby resolves the latest 3.3 patch, as before). Co-Authored-By: Claude <noreply@anthropic.com> * NAPP-179: update fastlane to 2.241.1 to clear the rubyzip alert The one open Dependabot alert (high) is rubyzip 2.4.1, fixed in 3.4.0, and fastlane 2.237.0 caps rubyzip below 3. fastlane 2.241.1, the version Guardian.swift already uses, allows rubyzip 3, so the pin moves there and the lock updates conservatively to fastlane's own dependencies (rubyzip 3.7.0, faraday 2). Build tooling only: the SDK artifact is built and published by Gradle. fastlane loads and lists all five lanes with the new lock. Co-Authored-By: Claude <noreply@anthropic.com> * NAPP-185: add a Validate release workflow that checks every part of a release Same design as Guardian.swift#189, adapted to the manual Portal promotion. Validate release (validate-release.yml, logic in .github/scripts/validate-release.sh) checks one version and writes a pass or fail table to the job summary, and fails if any check fails. It is read-only. Stage staged runs as the last job of Release: the GitHub Release is published, marked Latest when it is the highest version, and its notes match the CHANGELOG entry at the tag; no draft is left behind; the tag points at the merge commit of the newest merged release PR, which is on master and Verified; master's .version and README install line are at this version or later; and the newest Release run for the version succeeded. Stage published is started by hand after clicking Publish in the Portal and adds that repo1.maven.org serves the POM, the AAR and their .asc signatures (polling up to wait-minutes), that the POM has the right version, and that Maven resolves the exact artifact. The staging deployment in the Portal is not checked, because reading it needs the Maven Central credentials, which only the approved publish job may use. Run locally, the Maven Central rows pass for the published 0.11.2, and for 0.11.3, which was only a pipeline test run, it correctly reports no Release, no tag and nothing on Maven Central. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
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
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.
Releases 0.11.3: sets
.versionand the README install line, and adds the CHANGELOG entry.Before merging: