Skip to content

fix(build): use release commit timestamps for Maven artifacts - #842

Merged
zhongkechen merged 2 commits into
aws:mainfrom
zhongkechen:fix/release-artifact-timestamp
Oct 27, 2026
Merged

zhongkechen merged 2 commits into
aws:mainfrom
zhongkechen:fix/release-artifact-timestamp

Conversation

@zhongkechen

@zhongkechen zhongkechen commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

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

Issue Link, if available

Related: #841 (closed) ultimately proposed a fixed timestamp in the parent POM, updated manually each release. This PR derives the timestamp automatically from the release commit and has no dependency on #841.

Description

Maven 3.10.0 enables reproducible builds by default and sets project.build.outputTimestamp to 1980-02-01T00:00:00Z in its Super POM. The 2.3.0 release used Maven 3.10.0 from ubuntu-latest, so Maven Javadoc Plugin 3.12.0 derived the copyright year from that default and published Copyright © 1980.

The release workflow now runs set_release_timestamp.sh before building. It writes MAVEN_ARGS=-Dproject.build.outputTimestamp=<release commit time> to GITHUB_ENV. Git's %ct supplies a stable epoch timestamp from the checked-out release commit. The environment reaches both the initial build and each Maven subprocess in maven_publish.sh. Javadoc continues to omit generation dates for reproducibility.

Evidence: Maven 3.10.0 release notes, its Super POM, and the 2.3.0 release runner's software manifest.

Regression coverage design

The original local checks were not retained, so future changes could restore the 1980 fallback without a failing CI check. Share the timestamp setup script between the release workflow and committed Python unittest coverage, and run those tests in a dedicated read-only CI job on relevant PRs and main pushes.

A unit test creates a real Git commit with different author and committer dates and checks the emitted environment. An integration test applies that environment to real Maven, using the SDK's actual Javadoc plugin configuration in a small Java fixture with the 1980 default. It verifies footer years, suppressed generation dates, archive timestamps, and identical JAR bytes across two time zones. The fixture's committer date is January 1, 2031 at UTC+14, which falls in UTC year 2030.

Decisions and alternatives:

  • Use the committer timestamp so reruns of the same release keep the same date without a manual POM edit.
  • Set Maven's existing property once through MAVEN_ARGS (supported since Maven 3.9.0), avoiding repeated arguments in build/publish commands.
  • Extract the setup into one shared script so tests exercise production code without copying its shell expression or introducing a YAML parsing dependency.
  • Use real Git and Maven with a small fixture; checking YAML text alone would not verify the Maven/Javadoc behavior, and rebuilding the whole SDK would add unnecessary test cost. No Python packages or SDK dependencies are added.
  • Keep reproducibility enabled and limit the timestamp override to release packaging. Local builds and the separate Pages workflow retain their existing behavior. No SDK API or runtime changes.

Demo/Screenshots

Published Javadoc before: Copyright © 1980. All rights reserved.

After: the release commit's UTC year, e.g. Copyright © 2026. All rights reserved. for a 2026 release commit.

Checklist

  • I have filled out every section of the PR template
  • I have thoroughly tested this change

Testing

Run both retained tests with Python 3, Git, Maven >=3.9, and JDK 17:

python3 .github/scripts/test_release_timestamp.py -v

Unit Tests

test_uses_committer_timestamp_instead_of_author_or_wall_clock passes. It checks the exact environment value against the fixture's independently specified committer date, which differs from its author date and the wall clock.

Integration Tests

test_javadoc_uses_release_year_and_is_reproducible passes with real Maven 3.10.0 and Amazon Corretto 17. It verifies the fixture's UTC year 2030, no generation dates or dc.created, commit-derived ZIP timestamps, and byte-identical Javadoc JARs after clean builds in UTC and Pacific/Kiritimati.

Temporarily removing the timestamp override made this same retained test fail in both time zones: actual footer year 1980, expected 2030. Restoring the script made both tests pass (about five seconds with cached Maven dependencies).

Bash syntax, Python compilation, YAML parsing, and git diff --check passed. CI runs the retained tests when the release workflow, timestamp setup, tests, test workflow, or parent POM changes.

Unverified: the full GitHub release job, artifact signing, and Central upload were not run. SDK runtime tests were not rerun because the change supplies and tests Maven's release timestamp.

Examples

Not applicable; no SDK API or example changes.

@zhongkechen
zhongkechen requested a review from a team October 27, 2026 21:44
@zhongkechen
zhongkechen temporarily deployed to ai-pr-review-runtime October 27, 2026 21:44 — with GitHub Actions Inactive
@zhongkechen

Copy link
Copy Markdown
Contributor Author

/ai review

@zhongkechen

Copy link
Copy Markdown
Contributor Author

AI review workflow failed because this PR is from my fork.

Comment thread .github/workflows/publish_maven.yml Resolved
@github-actions

Copy link
Copy Markdown
Contributor

Codex AI review

One approach finding at .github/workflows/publish_maven.yml:81: required regression coverage is missing. Review was read-only; tests were not executed.

Reviewed commit 15cb27d0e2d11afc1fa52cc1f7af3b065e1444ff. Workflow run

@zhongkechen
zhongkechen merged commit 64339d4 into aws:main Oct 27, 2026
17 of 19 checks passed
@zhongkechen
zhongkechen deleted the fix/release-artifact-timestamp branch October 27, 2026 22:08
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