hudi-agent commented on code in PR #18747:
URL: https://github.com/apache/hudi/pull/18747#discussion_r3249955891
##########
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
Review Comment:
🤖 It might help to explicitly instruct the release manager to verify that
all artifacts have landed in the Java 11 staging repo (e.g., by spot-checking
in the Nexus UI or relying on the end-of-run success summary) **before**
dropping the Java 17 staging repo. As written, the step sequences "run the
copy" → "drop the Java 17 repo" → "review all staged artifacts" (step 6), so if
the copy silently missed something, the source artifacts would already be gone
when the review happens.
<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)
Review Comment:
🤖 Worth confirming: does the script require the target (Java 11) staging
repo to be in the "open" state as well? The note says "Make sure both repos are
still in the 'open' state (not closed)" — if Nexus rejects uploads to a closed
repo, it might be useful to mention what error the user would see, or whether
the script surfaces a clear message in that case.
<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>
+ ```
Review Comment:
🤖 Since both invocations use a relative path
(`./scripts/release/copy_staging_repo.sh`), it could clarify that the commands
should be run from the repository root, consistent with the convention used
elsewhere in the guide.
<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]
