Repository navigation
Release pipeline fixes from the first live releases (Android side of NAPP-177 to NAPP-186) - #202
Merged
manigandanparthasarathi-okta merged 7 commits intoOct 28, 2026
Conversation
…e 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>
…ise 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>
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>
…d 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>
…wift 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>
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>
… 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>
manigandanparthasarathi-okta
marked this pull request as ready for review
October 28, 2026 05:47
anirudh3997
approved these changes
Oct 28, 2026
manigandanparthasarathi-okta
deleted the
feature/release-pipeline-fixes
branch
October 28, 2026 06:18
arunav-gandhi
added a commit
that referenced
this pull request
Nov 11, 2026
arunav-gandhi
added a commit
that referenced
this pull request
Nov 11, 2026
* [NAPP-244] Fix jackson and java-jwt CVEs (ESD-71218) Bump com.auth0:java-jwt 4.6.1 -> 4.6.2 and the jackson-bom pin 2.22.2 -> 2.22.4, and declare jackson-core / jackson-databind directly (explicit 2.22.4) so Maven consumers and POM-only scanners also resolve the patched version. java-jwt 4.6.2 still pulls Jackson 2.22.3, which is affected by CVE-2026-110879. Addresses CVE-2026-85473 (java-jwt), CVE-2026-89425 and CVE-2026-89407 (jackson-core), CVE-2026-91776, CVE-2026-91777 and CVE-2026-110879 (jackson-databind). Co-Authored-By: Claude <noreply@anthropic.com> * [NAPP-244] Add Security entry to the 0.11.3 CHANGELOG section Prepare release does not rewrite an existing CHANGELOG entry (correction mode), so record the jackson / java-jwt CVE fixes here and update the date. Co-Authored-By: Claude <noreply@anthropic.com> * [NAPP-244] Add PRs merged since the 0.11.3 CHANGELOG entry was generated #188, #202, #204, #205 and #206 landed after the entry was drafted on Oct 21. 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.
Android side of the pipeline fixes in auth0/Guardian.swift#189, from the first live releases. Pipeline and build tooling only: no SDK sources, Gradle build or published artifact change, so nothing changes for consumers. One commit per ticket. Guardian.swift#189 was approved and merged with no review changes, so the shared steps here are as reviewed there.
Changes
Testing
🤖 Generated with Claude Code