[alonsopf89]

Summary

Configures Maven Central release staging for google/auto through Google's OSS Exit Gate (auto/mavencentral).

Key Changes

• Artifact Registry Staging Target: Stages release artifacts to us-maven.pkg.dev/oss-exit-gate-prod/auto--mavencentral via the oss-exit-gate publishing profile/repository (leaving normal builds, unit tests, and snapshot workflows unaffected).
• Preemptive Staging Cleanup & Release Manifest: Before publishing a new release, stale packages in auto--mavencentral should be cleaned via gcloud artifacts packages list/delete, followed by uploading manifest.json ({"publish_all": true}) to gs://oss-exit-gate-prod-projects-bucket/auto/mavencentral/manifests/ to trigger OSS Exit Gate verification and Maven Central publication:

  # 1. Clean up stale releases from staging repo
  packages=$(gcloud artifacts packages list \
      --project="oss-exit-gate-prod" \
      --location="us" \
      --repository="auto--mavencentral" \
      --format="value(name)" 2>/dev/null)
  echo "${packages}" | xargs -r -I {} sh -c '
      gcloud artifacts packages delete "{}" \
          --project="oss-exit-gate-prod" \
          --location="us" \
          --repository="auto--mavencentral" \
          --quiet
  '
  
  # 2. Stage signed artifacts & upload release manifest
  mvn deploy -P sonatype-oss-release,oss-exit-gate
  echo '{"publish_all": true}' > /tmp/manifest.json
  gcloud storage cp /tmp/manifest.json \
      "gs://oss-exit-gate-prod-projects-bucket/auto/mavencentral/manifests/manifest-$(date +%s).json"

• Verification: OSS Exit Gate resources (auto--mavencentral) are provisioned and end-to-end Artifact Registry + GCS manifest smoke testing has been verified (HTTP 201 + rc=0).

---

Internal Reference (for Google maintainers):

• Documentation & Migration Guide: http://go/oss-exit-gate (internal to google3)
• Buganizer Tracking Issue: http://b/576673325 (Parent Epic: http://b/576673325) (auto/mavencentral) | Onboarding CL: http://cl/1014638218

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[cpovirk]

Since our team has a number of OSS projects, I'm going to try to get one of them set up first (google/guava#8843) and then come back for the others.

For most of our projects, the source of truth is Piper, so we'll end up submitting CLs there instead of merging PRs directly. I came here to suggest CLs instead of PRs, but I'm realizing (a) that it's not necessarily clear which projects are "ours" and which of those have a Piper source of truth and (b) that it's simpler to test Maven builds with a PR than with a CL—except that we do need to approve workflow runs for PRs and not for CLs. So I guess it's more of a mixed bag than I thought a couple minutes ago.