feat(release): add changelog entry, GitHub Releases, lastPublished, a… by fabisev · Pull Request #640 · aws/aws-lambda-java-libs

fabisev · 2026-08-24T10:46:09Z

Issue #, if available: N/A

Description of changes:

Adds changelog and release-visibility improvements to both Maven Central release workflows, pulls the shared release logic into composite actions, and tightens up version and secret handling. No change to the build itself.

.github/workflows/release.yml (pure-Java modules)

New required changelogEntry input. It's prepended to the module's RELEASE.CHANGELOG.md (committed into the post-release version-bump PR) and reused as the GitHub Release notes. Passed via env, never interpolated into the shell.
New step to create a GitHub Release on the pushed tag. It includes:
- the changelog entry plus a link to the Maven Central artifact;
- the signed jars (*.jar) and their detached signatures (*.jar.asc) (the exact same signatures published to Maven Central, made with the shared Lambda Java release signing key, no re-signing);
- signature-verification instructions in the notes (import the public key from a keyserver by fingerprint, then gpg --verify). Only the public key fingerprint crosses $GITHUB_ENV; the GPG passphrase and Sonatype token stay in-shell and are scrubbed on exit.
New step to update a lastPublished marker in the module POM (see below) on each release.
Module POMs now set a meaningful Central deploymentName (groupId:artifactId:version) so the Central Portal deployment is labeled by GAV instead of the default "DEPLOYMENT".

.github/workflows/release-runtime-interface-client.yml (RIC)

Brought in line with release.yml: the required changelogEntry input, the shared GitHub Release step, and the lastPublished marker refresh. For RIC the release also attaches the native classifier jars (linux and linux_musl, x86_64 and aarch64) next to the main jar and their .asc signatures.
The inline Corretto 8 setup is now the shared setup-corretto8 action (see below).

Shared composite actions

create-github-release: builds the notes (changelog, Central link, verify instructions) and attaches only signed, published artifacts. The asset list is derived from the .asc files, so unsigned intermediates like shade's original-*.jar never get attached. Used by both workflows.
setup-corretto8: points JAVA_HOME and PATH at the runner image's preinstalled Corretto 8 ($JAVA_8_HOME) and writes a Maven toolchains.xml. Avoids actions/setup-java, which reaches hosts the runner egress lock blocks. Used by both workflows.

Hardening

resolve-release-version now checks the effective release version against a strict MAJOR.MINOR.PATCH[-prerelease] shape and rejects -SNAPSHOT. That string later lands in a sed program, in git tag and branch names, and in $GITHUB_ENV, so the allowed characters deliberately leave out sed delimiters and metacharacters, whitespace, and newlines. This also puts release-version validation on the same footing as the existing developmentVersion check.
Both workflows now pass the GPG passphrase to Maven through MAVEN_GPG_PASSPHRASE (the gpg plugin reads it directly) instead of -Dgpg.passphrase=..., keeping it out of the process argument list and out of release:perform's space-split -Darguments.
The RIC release job re-checks that it's running on main, since it publishes on a different runner than the build-natives job that already does that check.

Module POMs (core, events, events-sdk-transformer, log4j2, serialization, tests, runtime-interface-client)

Added a  comment under <version> recording the last version published to Central, seeded with each module's current latest. Informational only (Maven ignores it); auto-updated by the release workflow.
Added the <deploymentName> config to the central-publishing-maven-plugin.

RELEASING.md

New maintainer doc: how to cut a release, what the workflow does, dry runs, and failure handling.

Note: the shared parent-POM / version-map change that was previously part of this branch has been split into a separate follow-up PR and is not included here.

Target (OCI, Managed Runtime, both): both

…nd RELEASING.md

codecov · 2026-08-24T10:51:49Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.79%. Comparing base (89647db) to head (baa4cd5).

Additional details and impacted files

@@            Coverage Diff            @@
##               main     #640   +/-   ##
=========================================
  Coverage     65.79%   65.79%           
  Complexity      214      214           
=========================================
  Files            34       34           
  Lines           991      991           
  Branches        143      143           
=========================================
  Hits            652      652           
  Misses          287      287           
  Partials         52       52

Flag	Coverage Δ
aarch64	`65.79% <ø> (ø)`
x86_64	`65.38% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ 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.

darklight3it · 2026-08-28T14:41:07Z

+          # (2) Parent version map — keyed only for modules other modules depend on.
+          case "$MODULE" in
+            aws-lambda-java-core)          PROP=lambda.core.version ;;
+            aws-lambda-java-events)        PROP=lambda.events.version ;;
+            aws-lambda-java-serialization) PROP=lambda.serialization.version ;;
+            *)                             PROP="" ;;


I don't like this hard mapping for different reasons.

First are we assuming that we are can have multiple tags right? Is this a good experience?

Why only those packages and not all the packages we are publishing on Maven.

In the case we need a subset why don't you create a properties you can read from the pom that directly tells you if you need to read the version?

darklight3it · 2026-08-28T14:42:14Z


+  <parent>
+    <groupId>com.amazonaws</groupId>
+    <artifactId>aws-lambda-java-libs-parent</artifactId>


I think you can just call it aws-java-libs, the "parentness" of that package is implied by the <parent/> tag.

darklight3it · 2026-08-28T14:44:22Z

+    <properties>
+        <lambda.core.version>1.4.0</lambda.core.version>
+        <lambda.events.version>3.16.1</lambda.events.version>
+        <lambda.serialization.version>1.4.1</lambda.serialization.version>
+    </properties>


Why only those packages? Also double check their version.

darklight3it · 2026-08-28T14:45:31Z

+    <dependencyManagement>
+        <dependencies>
+            <dependency>
+                <groupId>com.amazonaws</groupId>
+                <artifactId>aws-lambda-java-core</artifactId>
+                <version>${lambda.core.version}</version>
+            </dependency>
+            <dependency>
+                <groupId>com.amazonaws</groupId>
+                <artifactId>aws-lambda-java-events</artifactId>
+                <version>${lambda.events.version}</version>
+            </dependency>
+            <dependency>
+                <groupId>com.amazonaws</groupId>
+                <artifactId>aws-lambda-java-serialization</artifactId>
+                <version>${lambda.serialization.version}</version>
+            </dependency>
+        </dependencies>
+    </dependencyManagement>


I think in this file you can also define version number of transitive dependencies.

Move the shared parent POM and everything that depends on it out of this PR into a stacked follow-up, so this PR carries only the release-workflow features that stand on their own: - changelogEntry input, GitHub Release creation, signed-jar attachment and signature-verification notes - per-module lastPublished markers and Central deploymentName Removed here (returns in the follow-up PR): - root pom.xml (centralized version map + flatten plugin) - <parent> blocks and "version managed by parent" comments in modules - release.yml parent-version-map step and the version-map property in the cross-module test gate - the parent-version-map mention in RELEASING.md and the .flattened-pom.xml .gitignore entry

…thub-releases' into fabisev/release-changelog-and-github-releases

Add reusable setup-corretto8 and create-github-release composite actions; attach the signed jars + .asc signatures (same as Maven Central) with GPG verification notes, and add changelog + lastPublished to the RIC release.

…thub-releases' into fabisev/release-changelog-and-github-releases

anzheyazzz · 2026-09-02T22:40:23Z

          mvn deploy -Prelease -DskipTests -DmultiArch=false \
            -gs "$MAVEN_SETTINGS" \
-            -Dgpg.keyname="$GPG_KEYNAME" -Dgpg.passphrase="$GPG_PASSPHRASE" \
+            -Dgpg.keyname="$GPG_KEYNAME" \


I can see the plugin maven-gpg-plugin version are all v1.5, does it support this new feature? Do we need to bump the version of maven-gpg-plugin as well?

Nice catch. The example provided here is with the new version which is 3.2.8

https://maven.apache.org/plugins/maven-gpg-plugin/usage.html

This seems to me something we can add later. Can we descope it in another PR?

anzheyazzz · 2026-09-02T22:54:02Z

+          version: ${{ env.EFFECTIVE_RELEASE_VERSION }}
+          changelog-entry: ${{ env.CHANGELOG_ENTRY_INPUT }}
+          fingerprint: ${{ env.GPG_FINGERPRINT }}
+          artifact-dir: ${{ env.MODULE }}/target/checkout/target


It passes <module>/target/checkout/target here, but I think release:perform builds the module under path like <module>/target/checkout/<module>/target

+1. If I can suggest can we just create the env where mvn has created the artifact just after we create it? Also let's fail if we don't find a valid artifact.

darklight3it · 2026-09-03T09:19:49Z

          mvn deploy -Prelease -DskipTests -DmultiArch=false \
            -gs "$MAVEN_SETTINGS" \
-            -Dgpg.keyname="$GPG_KEYNAME" -Dgpg.passphrase="$GPG_PASSPHRASE" \
+            -Dgpg.keyname="$GPG_KEYNAME" \


Nice catch. The example provided here is with the new version which is 3.2.8

https://maven.apache.org/plugins/maven-gpg-plugin/usage.html

This seems to me something we can add later. Can we descope it in another PR?

darklight3it · 2026-09-03T09:52:59Z

+          version: ${{ env.EFFECTIVE_RELEASE_VERSION }}
+          changelog-entry: ${{ env.CHANGELOG_ENTRY_INPUT }}
+          fingerprint: ${{ env.GPG_FINGERPRINT }}
+          artifact-dir: ${{ env.MODULE }}/target/checkout/target


+1. If I can suggest can we just create the env where mvn has created the artifact just after we create it? Also let's fail if we don't find a valid artifact.

darklight3it · 2026-09-03T10:30:26Z

@@ -354,6 +355,24 @@ jobs:
            --title "chore(release): ${MODULE} ${EFFECTIVE_RELEASE_VERSION}" \
            --body "Post-release version bump for ${MODULE} ${EFFECTIVE_RELEASE_VERSION} (already on Maven Central, tag ${TAG_NAME} pushed)."


I think we can probably extract this. This is really similar code to the one in release.

feat(release): add changelog entry, GitHub Releases, lastPublished, a…

cf830ff

…nd RELEASING.md

fabisev and others added 2 commits August 25, 2026 11:05

Merge branch 'main' into fabisev/release-changelog-and-github-releases

3bde5cb

build: centralize module versions in a parent POM

555b3f5

darklight3it requested review from darklight3it and maxday August 25, 2026 14:07

fabisev added 2 commits August 26, 2026 11:28

Merge branch 'main' into fabisev/release-changelog-and-github-releases

cff1683

Merge branch 'main' into fabisev/release-changelog-and-github-releases

45420b7

darklight3it reviewed Aug 28, 2026

View reviewed changes

fabisev added 13 commits August 31, 2026 11:20

refactor(release): address PR review on parent POM and workflow

5d51046

docs(release): shorten version-map comment

ce9f80b

chore(release): set meaningful Central deploymentName (GAV)

5a6a528

feat(release): attach signed jars + verify notes to GitHub Release

f980a36

Merge branch 'main' into fabisev/release-changelog-and-github-releases

0d41205

Merge remote-tracking branch 'origin/fabisev/release-changelog-and-gi…

9bc7a4a

…thub-releases' into fabisev/release-changelog-and-github-releases

feat(release): attach signed jars to GitHub Releases

91ebbbc

Add reusable setup-corretto8 and create-github-release composite actions; attach the signed jars + .asc signatures (same as Maven Central) with GPG verification notes, and add changelog + lastPublished to the RIC release.

Merge branch 'main' into fabisev/release-changelog-and-github-releases

e9d9111

fix(release): validate release version and keep GPG passphrase off argv

7363371

chore(release): squash post-release bump into one commit

649ce7e

Merge remote-tracking branch 'origin/fabisev/release-changelog-and-gi…

b3d7b5b

…thub-releases' into fabisev/release-changelog-and-github-releases

refactor(release): centralize release tag in TAG_NAME

baa4cd5

anzheyazzz reviewed Sep 2, 2026

View reviewed changes

darklight3it reviewed Sep 3, 2026

View reviewed changes

Navigation Menu

Uh oh!

feat(release): add changelog entry, GitHub Releases, lastPublished, a… - #640

feat(release): add changelog entry, GitHub Releases, lastPublished, a…#640
fabisev wants to merge 18 commits into
mainfrom
fabisev/release-changelog-and-github-releases

fabisev commented Aug 24, 2026 •

edited

Loading

Uh oh!

codecov Bot commented Aug 24, 2026 •

edited

Loading

Uh oh!

darklight3it Aug 28, 2026

Uh oh!

darklight3it Aug 28, 2026

Uh oh!

darklight3it Aug 28, 2026

Uh oh!

darklight3it Aug 28, 2026

Uh oh!

anzheyazzz Sep 2, 2026

Uh oh!

darklight3it Sep 3, 2026

Uh oh!

anzheyazzz Sep 2, 2026

Uh oh!

darklight3it Sep 3, 2026

Uh oh!

darklight3it Sep 3, 2026

Uh oh!

darklight3it Sep 3, 2026

Uh oh!

darklight3it Sep 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

		@@ -354,6 +355,24 @@ jobs:
		--title "chore(release): ${MODULE} ${EFFECTIVE_RELEASE_VERSION}" \
		--body "Post-release version bump for ${MODULE} ${EFFECTIVE_RELEASE_VERSION} (already on Maven Central, tag ${TAG_NAME} pushed)."

Uh oh!

Conversation

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

Uh oh!

Uh oh!

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

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fabisev commented Aug 24, 2026 •

edited

Loading

codecov Bot commented Aug 24, 2026 •

edited

Loading