Skip to content

Release pipeline fixes from the first live releases (Android side of NAPP-177 to NAPP-186) - #202

Merged
manigandanparthasarathi-okta merged 7 commits into
masterfrom
feature/release-pipeline-fixes
Oct 28, 2026
Merged

manigandanparthasarathi-okta merged 7 commits into
masterfrom
feature/release-pipeline-fixes

Conversation

@manigandanparthasarathi-okta

@manigandanparthasarathi-okta manigandanparthasarathi-okta commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

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

  • NAPP-177 (Detect release): reads the release PR number from the squash title first, then falls back to the commit-to-PR lookup with 6 attempts 5 seconds apart, so a run that starts right after the merge no longer skips the release (seen on Guardian.swift 1.10.0). The step is identical to the iOS one.
  • NAPP-186 (approval request): the publish job is now "Publish Guardian.Android X.Y.Z to Maven Central staging", shown in the review email and approval dialog. Validate version writes a job summary with the SDK, version, commit, release PR, how tests were covered, a reminder that approval only uploads to staging, and the full CHANGELOG entry. The supersede check matches the job by prefix.
  • NAPP-183 (staging_dropped wording): the checkbox reads "Replace an unpublished upload: tick only after you clicked Drop on this version's earlier upload in the Maven Central Portal", the preflight error says exactly what to do, and a comment lists when to tick it and when not to. The input name and behaviour are unchanged.
  • NAPP-182 (duplicate tests): Release skips its Test job when the merge commit's tree is identical to the release PR head and the PR's Test check passed there. Otherwise it runs as before. 0.11.3 would have qualified. The check step is identical to the iOS one.
  • NAPP-185 (Validate release): new reusable workflow with two stages. Stage staged runs at the end of Release and checks the GitHub Release, its notes, drafts, Latest, the tag, master's versions and the Release run. Stage published is run by hand after clicking Publish in the Portal and also checks that Maven Central serves the POM, AAR and signatures and that the version resolves. The Portal staging deployment is not checked because that needs the release credentials.
  • NAPP-179 (tooling, in step with Guardian.swift): Ruby 3.2 to 3.3, and fastlane 2.237.0 to 2.241.1 (the version Guardian.swift uses), which allows rubyzip 3 and clears the one open Dependabot alert (rubyzip, high).

Testing

  • actionlint and shellcheck pass on all changed workflows and scripts.
  • The Detect release and tree check steps are byte for byte the iOS ones, which were checked against real merges in Guardian.swift#189. For 0.11.3 the merge commit and PR head trees are identical and the PR's Test check passed.
  • Validate release run locally: for 0.11.3, which was only a pipeline test run, it reports no Release, no tag and nothing on Maven Central; for the published 0.11.2 the Maven Central and POM rows pass.
  • fastlane 2.241.1 loads and lists all five lanes with the new lock. This PR's checks are the first run on Ruby 3.3.
  • Release and Validate release (published) get their first full run at the next Android release.

🤖 Generated with Claude Code

…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
manigandanparthasarathi-okta marked this pull request as ready for review October 28, 2026 05:47
@manigandanparthasarathi-okta
manigandanparthasarathi-okta merged commit 7ab2837 into master Oct 28, 2026
4 checks passed
@manigandanparthasarathi-okta
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
#188, #202, #204, #205 and #206 landed after the entry was drafted on Oct 21.

Co-Authored-By: Claude <noreply@anthropic.com>
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>
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