Fabisev/automating mvn deployment by fabisev · Pull Request #626 · aws/aws-lambda-java-libs

fabisev · 2026-07-24T12:57:00Z

Issue #, if available:

Description of changes:

Replaces the manual mvn deploy release with GitHub Actions release pipelines that build, test, sign, and publish CI-validated artifacts to Maven Central.

release.yml: workflow_dispatch pipeline for the six pure-Java modules. Pinned JDK 8, mvn verify gate, then release:prepare/release:perform with a publish-safe ordering (prepare locally, publish, then git push --atomic only after publish succeeds; failure rolls back the runner and never modifies the remote). Repo-wide release concurrency group so releases never overlap.
release-runtime-interface-client.yml: dedicated RIC pipeline. RIC ships a JNI native library for four targets plus a main JAR, so each native library is built on a runner of its own architecture (x86_64 on ubuntu-latest, aarch_64 on ubuntu-24.04-arm) instead of QEMU emulation, then one job assembles all artifacts and publishes them.
POM changes across all modules: SNAPSHOT versions, maven-release-plugin configuration, SCM developerConnection, and autoPublish=true.
Credentials are fetched at runtime via GitHub OIDC

Testing done:

Validated locally with act (GitHub Actions run in a container)

Workflow mechanics (dry-run of release.yml): checkout, pinned JDK 8, mvn verify, and release:prepare -DdryRun pass; correct release tag and next-development version bump.
Publish chain (against a personal Sonatype namespace I control, with auto-publish disabled and the deployment dropped afterward): GPG signing, token auth, upload, and Sonatype validation all succeed with no errors, exercising the same signing/settings/publishing mechanic the real workflow uses.
log4j2 module correctness (built on pinned JDK 8): the jar contains the Log4j2Plugins.dat descriptor, classes are Java 8 bytecode, and the descriptor unit test passes.
RIC native build: the arm64 classifier jar was built on JDK 8 and contains a correct ARM aarch64 ELF shared object.
RIC multi-artifact publish shape: a main jar plus four classifier jars deploy as a single deployment and validate with no errors.
Credential fetch (read-only)

Not exercisable outside a real run in this repo: the live token exchange and the CI build-matrix assembly. These will be covered by the first dry-run (skip_publish: true) after merge.

Target (OCI, Managed Runtime, both): N/A

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Add maven-release-plugin configuration with module-specific tag formats and SCM connection details to enable automated Maven deployments across all library modules.

Combine the maven-release-plugin/SCM/autoPublish config (this branch) with the maven-toolchains-plugin added on main (PR #617) so every module carries both plugins in a single <build> section.

Add .github/workflows/release.yml, a workflow_dispatch pipeline that builds, tests, and publishes a single module to Maven Central in one pinned JDK 8 environment, replacing the manual mvn deploy from a developer workstation. The release step prepares locally, publishes, then pushes the commits and module-scoped tag atomically, so a failed publish never leaves an orphan tag on the remote; a failure path rolls back the runner state. Releases are serialized repo-wide via a shared concurrency group. Signing/publishing secrets are not wired yet, so only the dry-run path (skip_publish) works without credentials for now. Set all module versions to -SNAPSHOT as the release plugin's expected starting point, and merge a duplicate top-level <build> section in the events POM introduced when the toolchains change (PR #617) met the release-plugin config on this branch.

codecov · 2026-07-24T13:43:06Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.38%. Comparing base (371508e) to head (8fbec4a).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main     #626   +/-   ##
=========================================
  Coverage     65.38%   65.38%           
  Complexity      212      212           
=========================================
  Files            34       34           
  Lines           991      991           
  Branches        143      143           
=========================================
  Hits            648      648           
  Misses          290      290           
  Partials         53       53

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

… into fabisev/automating-mvn-deployment # Conflicts: # aws-lambda-java-runtime-interface-client/pom.xml

darklight3it · 2026-07-28T12:16:45Z

+          export GNUPGHOME
+          gpgconf --kill gpg-agent || true
+          gpg --batch --import <<< "$GPG_PRIVATE_KEY"
+          GPG_KEYNAME=$(gpg --list-secret-keys --with-colons | awk -F: '/^sec:/ {print $5; exit}')


Here we are blindly trusting whatever is coming from the secrets manager. We can make this code stronger catching someone that is trying to tamper the private keys in this way.

gpg --batch --import <<< "$GPG_PRIVATE_KEY" # Verify the imported key matches the expected fingerprint. ACTUAL_FPR=$(gpg --list-secret-keys --with-colons | awk -F: '/^fpr:/ {print $10; exit}') if [[ "$ACTUAL_FPR" != "$EXPECTED_GPG_FINGERPRINT" ]]; then echo "::error::GPG key fingerprint mismatch: expected $EXPECTED_GPG_FINGERPRINT, got $ACTUAL_FPR" exit 1 fi GPG_KEYNAME=$(gpg --list-secret-keys --with-colons | awk -F: '/^sec:/ {print $5; exit}')

Essentially we double check that the gpg is conformant to what is published on the keyserver in its public part.

This is a little bit convoluted for now but we should consider doing that in a follow up.

darklight3it · 2026-07-28T12:25:21Z

+    environment: Release
+    timeout-minutes: 30
+
+    steps:


Since this is manual can we add a guard to avoid branch deploy?

- name: Verify release branch run: | if [[ "$GITHUB_REF_NAME" != "main" ]]; then echo "::error::Releases must run from the main branch, got '$GITHUB_REF_NAME'" exit 1 fi - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6 ...

darklight3it · 2026-07-28T12:37:18Z

+          role-session-name: GitHubActionsRicMavenCentralRelease
+          role-duration-seconds: 3600
+
+      - name: Fetch signing key and Sonatype credentials


I think there is a lot of space here to create a custom action to make this logic reusable between the two workflows.

darklight3it · 2026-07-28T12:38:18Z

+  AWS_REGION: ${{ vars.AWS_REGION_MAVEN_RELEASE }}
+  OIDC_ROLE_ARN: ${{ secrets.AWS_ROLE_MAVEN_RELEASE }}
+
+jobs:


Add the guard here too.

- Extract resolve-release-version and configure-release-aws-credentials composite actions shared by both release workflows - Fetch signing key + Sonatype token inside the publish step so secrets never cross $GITHUB_ENV; scrub settings.xml and keyring on exit - Guard releases to the main branch; cut OIDC role session to 300s - Set RIC to 2.12.0-SNAPSHOT so the release pipeline can publish it

- log4j2 gates on the CloudWatch integration test (reusable workflow), bound to the publish event - serialization gates on the aws-lambda-java-tests suite (version-overridden), which its own mvn verify does not run

darklight3it · 2026-07-29T14:24:23Z

+          # Scrub the settings.xml (contains the Sonatype token) and the keyring
+          # on exit, so no sensitive file is left on the runner even on failure.
+          MAVEN_SETTINGS="$RUNNER_TEMP/settings.xml"
+          export GNUPGHOME=$(mktemp -d)


Really good idea using an ephemeral folder 🚀 , this gives the guarantee of isolation on single jobs. We can probably use the same for $MAVEN_SETTINGS, since $RUNNERT_TEMP is phisical and we don't need this to survive that long.

darklight3it · 2026-07-29T14:38:54Z

+          # on exit, so no sensitive file is left on the runner even on failure.
+          MAVEN_SETTINGS="$RUNNER_TEMP/settings.xml"
+          export GNUPGHOME=$(mktemp -d)
+          trap 'rm -rf "$MAVEN_SETTINGS" "$GNUPGHOME"' EXIT


Also good idea using the trap here 🚀 . This cleans the data if there is a failure along the line.

darklight3it

LGTM 🚀

rudraroop

Overall, looks good - I do have a doubt about the reusability of this workflow

If you look at this file - run-integration-test.yml

It contains this block

on:
  workflow_dispatch:
....

From what I understand this allows workflows to be used but not reused or called by other workflows. I believe an additional block that looks like

on:
  workflow_call:
....

May be required. This is the impression I got from the official documentation - https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows - but I'm not sure if this repository handles things differently somehow

In any case, worth checking and confirming before we merge

release.yml invokes run-integration-test.yml as a reusable workflow via uses:, which GitHub requires the called workflow to declare with an on: workflow_call trigger. Without it the log4j2 release would fail when resolving the reusable workflow.

rudraroop

LGTM

rudraroop · 2026-07-30T14:49:16Z


 on:
  workflow_dispatch:
+  workflow_call:


Fabiana Severin added 4 commits July 14, 2026 17:09

build: Add maven-release-plugin and SCM config to all modules

52bd30d

Add maven-release-plugin configuration with module-specific tag formats and SCM connection details to enable automated Maven deployments across all library modules.

Merge origin/main into fabisev/automating-mvn-deployment

725d829

Combine the maven-release-plugin/SCM/autoPublish config (this branch) with the maven-toolchains-plugin added on main (PR #617) so every module carries both plugins in a single <build> section.

ci: Wire OIDC secrets and add native RIC release workflow

c9e1061

darklight3it requested review from darklight3it and rudraroop July 26, 2026 06:19

darklight3it added enhancement github_actions Pull requests that update GitHub Actions code labels Jul 26, 2026

Merge remote-tracking branch 'origin/feat/invocation-id-cross-wiring'…

e3223b5

… into fabisev/automating-mvn-deployment # Conflicts: # aws-lambda-java-runtime-interface-client/pom.xml

fabisev changed the base branch from main to feat/invocation-id-cross-wiring July 27, 2026 10:29

darklight3it requested a review from maxday July 28, 2026 10:57

darklight3it reviewed Jul 28, 2026

View reviewed changes

Fabiana Severin added 2 commits July 28, 2026 18:13

feat(release): gate publish on module-specific tests

b9418bc

- log4j2 gates on the CloudWatch integration test (reusable workflow), bound to the publish event - serialization gates on the aws-lambda-java-tests suite (version-overridden), which its own mvn verify does not run

fabisev force-pushed the fabisev/automating-mvn-deployment branch from 2feffe8 to b9418bc Compare July 28, 2026 22:45

darklight3it reviewed Jul 29, 2026

View reviewed changes

darklight3it approved these changes Jul 29, 2026

View reviewed changes

rudraroop reviewed Jul 30, 2026

View reviewed changes

Base automatically changed from feat/invocation-id-cross-wiring to main July 30, 2026 14:11

rudraroop approved these changes Jul 30, 2026

View reviewed changes

Comment thread .github/workflows/run-integration-test.yml

on:

workflow_dispatch:

workflow_call:

rudraroop Jul 30, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Neat

Uh oh!

Conversation

fabisev commented Jul 24, 2026

Uh oh!

codecov Bot commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

darklight3it Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

darklight3it Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

darklight3it Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

darklight3it Jul 28, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

darklight3it Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

darklight3it Jul 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

darklight3it left a comment

Choose a reason for hiding this comment

Uh oh!

rudraroop left a comment

Choose a reason for hiding this comment

Uh oh!

rudraroop left a comment

Choose a reason for hiding this comment

Uh oh!

rudraroop Jul 30, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov Bot commented Jul 24, 2026 •

edited

Loading

darklight3it Jul 29, 2026 •

edited

Loading

darklight3it Jul 29, 2026 •

edited

Loading