hudi-agent commented on code in PR #18747:
URL: https://github.com/apache/hudi/pull/18747#discussion_r3250645247
##########
release/release_guide.md:
##########
@@ -425,8 +425,23 @@ Set up a few environment variables to simplify Maven
commands that follow. This
module. See [checklist](#checklist-to-proceed-to-the-next-step).
2. Continue with Java 17 build for Spark 4 bundle, run `export
JAVA_HOME=$(/usr/libexec/java_home -v 17)` and
`/scripts/release/deploy_staging_jars_java17.sh 2>&1 | tee -a
"/tmp/${RELEASE_VERSION}-${RC_NUM}.deploy2.log"`
- 5. Note that the artifacts from Java 17 build are uploaded to a separate
staging repo. You need to manually
- download those artifacts and upload them to the first staging repo so
that all artifacts stay in the same repo.
+ 5. Note that the artifacts from Java 17 build are uploaded to a separate
staging repo. Use the
+ `copy_staging_repo.sh` script to copy all artifacts from the Java 17
staging repo into the Java 11 staging repo
+ so that all artifacts stay in the same repo.
+ 1. Identify both staging repo IDs from [Apache Nexus Staging
Repositories](https://repository.apache.org/#stagingRepositories)
+ (e.g., `orgapachehudi-1177` for Java 17, `orgapachehudi-1176` for
Java 11). Make sure both repos are still in
+ the "open" state (not closed).
+ 2. First do a dry-run to verify the list of artifacts to be copied:
+ ```shell
+ ./scripts/release/copy_staging_repo.sh --dry-run <java17-repo-id>
<java11-repo-id>
+ ```
+ 3. Then run the actual copy:
+ ```shell
+ ./scripts/release/copy_staging_repo.sh <java17-repo-id>
<java11-repo-id> 2>&1 | tee -a
"/tmp/${RELEASE_VERSION}-${RC_NUM}.copy_staging.log"
+ ```
+ 4. The script reads Nexus credentials from `~/.m2/settings.xml` (server
id `apache.releases.https`), downloads
+ every artifact from the source repo, and re-uploads them to the
target repo. After it finishes, drop the
+ Java 17 staging repo on Apache Nexus.
Review Comment:
🤖 Dropping the Java 17 staging repo right after the copy script finishes is
irreversible — if any artifact failed to upload (or if signatures/checksums are
missing), the original source is gone. This step could direct the release
manager to first complete the verification in step 6 (confirming the Java 11
repo contains all expected artifacts, including `.asc`/`.md5`/`.sha1` files for
each jar/pom) and only then drop the Java 17 repo.
<sub><i>- AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
##########
release/release_guide.md:
##########
@@ -425,8 +425,23 @@ Set up a few environment variables to simplify Maven
commands that follow. This
module. See [checklist](#checklist-to-proceed-to-the-next-step).
2. Continue with Java 17 build for Spark 4 bundle, run `export
JAVA_HOME=$(/usr/libexec/java_home -v 17)` and
`/scripts/release/deploy_staging_jars_java17.sh 2>&1 | tee -a
"/tmp/${RELEASE_VERSION}-${RC_NUM}.deploy2.log"`
- 5. Note that the artifacts from Java 17 build are uploaded to a separate
staging repo. You need to manually
- download those artifacts and upload them to the first staging repo so
that all artifacts stay in the same repo.
+ 5. Note that the artifacts from Java 17 build are uploaded to a separate
staging repo. Use the
+ `copy_staging_repo.sh` script to copy all artifacts from the Java 17
staging repo into the Java 11 staging repo
+ so that all artifacts stay in the same repo.
+ 1. Identify both staging repo IDs from [Apache Nexus Staging
Repositories](https://repository.apache.org/#stagingRepositories)
+ (e.g., `orgapachehudi-1177` for Java 17, `orgapachehudi-1176` for
Java 11). Make sure both repos are still in
+ the "open" state (not closed).
+ 2. First do a dry-run to verify the list of artifacts to be copied:
+ ```shell
+ ./scripts/release/copy_staging_repo.sh --dry-run <java17-repo-id>
<java11-repo-id>
+ ```
+ 3. Then run the actual copy:
+ ```shell
+ ./scripts/release/copy_staging_repo.sh <java17-repo-id>
<java11-repo-id> 2>&1 | tee -a
"/tmp/${RELEASE_VERSION}-${RC_NUM}.copy_staging.log"
+ ```
Review Comment:
🤖 It might help to clarify what the script considers an "artifact" —
specifically, does it also copy the accompanying `.asc` signature files and
`.md5`/`.sha1` checksum files that Apache releases require? If not, the
resulting Java 11 staging repo would fail signature verification during the
vote. Worth calling out explicitly in the doc (or confirming the script handles
them).
<sub><i>- AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
