fix: migrate new version validate-release.yml #31
Conversation
|
Note Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported. |
|
@codecov-ai-reviewer review |
概述删除了旧的发布验证工作流文件（validate-release-new.yml），同时对主工作流（validate-release.yml）进行了全面升级，将构建作业替换为验证作业，并添加了Java版本选择和多步骤发布验证流程。 变更清单
预估代码审查工作量🎯 3 (中等) | ⏱️ ~25 分钟 需特别关注的区域：
可能相关的拉取请求
诗句
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Tip ✨ Issue Enrichment is now available for GitHub issues!CodeRabbit can now help you manage issues more effectively:
Disable automatic issue enrichmentTo disable automatic issue enrichment, add the following to your issue_enrichment:
auto_enrich:
enabled: falseThanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.github/workflows/validate-release.yml (2)
97-132: 验证步骤的整体结构良好，但需关注路径模式的健壮性工作流的9个验证步骤设计合理，包含全面的ASF发布要求检查。然而，某些步骤中的
find命令使用了复杂的路径模式，这些模式可能对发布包结构的变化比较敏感。例如第504行的查找模式：
SERVER_DIR=$(find . -maxdepth 3 -type d -path "*hugegraph-incubating*src/hugegraph-server/*hugegraph*${{ env.RELEASE_VERSION }}" 2>/dev/null | head -n1)如果发布包的目录结构与预期不符，可能会返回空值，导致后续步骤失败。建议在找不到目录时提供更详细的诊断信息。
目前第506-508行有基础的错误检查，但可以改进诊断输出：
if [[ -z "$SERVER_DIR" ]]; then - echo "Error: Could not find compiled server directory" + echo "Error: Could not find compiled server directory" + echo "Expected pattern: *hugegraph-incubating*src/hugegraph-server/*hugegraph*${{ env.RELEASE_VERSION }}" + echo "Found directories:" + find . -maxdepth 3 -type d -name "*hugegraph*" | head -10 exit 1 fi建议对第504、541、604、730、747等类似的
find命令添加更好的错误诊断输出，以便在目录结构不匹配时能够快速定位问题。Also applies to: 220-492, 613-718
14-21: Update matrix configuration to support both Java versions in parallelThe workflow accepts Java version input (11 or 17) but the matrix at line 820 only includes
['11'], preventing parallel testing of both versions. While theJAVA_VERSIONenvironment variable correctly uses the workflow input when triggered viaworkflow_dispatch, the matrix configuration should include both versions to support comprehensive testing:strategy: fail-fast: false matrix: - java_version: ['11'] + java_version: ['11', '17'] os: [ubuntu-latest, macos-latest]This allows:
- Parallel testing of both Java versions on all OS combinations when triggered via
workflow_dispatch- Job names will accurately reflect which Java version is being tested
- Push/PR triggers will validate against both supported Java versions
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/validate-release-new.yml(0 hunks).github/workflows/validate-release.yml(3 hunks)
💤 Files with no reviewable changes (1)
- .github/workflows/validate-release-new.yml
🧰 Additional context used
🪛 actionlint (1.7.9)
.github/workflows/validate-release.yml
51-51: the runner of "actions/setup-java@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
| - name: Install JDK ${{ env.JAVA_VERSION }} | ||
| uses: actions/setup-java@v3 | ||
| with: | ||
| java-version: ${{ matrix.java_version }} | ||
| java-version: ${{ env.JAVA_VERSION }} | ||
| distribution: 'adopt' |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
actions/setup-java v4 latest version release 2024 2025
💡 Result:
Latest actions/setup-java v4 release: v4.8.0 — released 04 Dec 2025. [1]
Notable v4 releases in 2024–2025:
- v4.6.0 — 18 Dec 2024. [1]
- v4.5.0 — 24 Oct 2024. [1]
- v4.4.0 — 24 Sep 2024. [1]
Source: actions/setup-java Releases (GitHub). [1]
References
[1] https://github.com/actions/setup-java/releases
🌐 Web query:
actions/setup-java@v4 adopt distribution compatibility
💡 Result:
Short answer: actions/setup-java@v4 accepts a distribution input but "adopt" (AdoptOpenJDK) is legacy — the project and ecosystem migrated AdoptOpenJDK to Eclipse Temurin, so you should use distribution: "temurin" (or "adopt-hotspot" only for legacy workflows) to remain supported. See the action README and distribution docs. [1][2]
Sources:
- actions/setup-java README (supported distributions & Adopt→Temurin note). [1]
- setup-java distributions list / docs (notes recommending migration from adopt to temurin). [2]
Update actions/setup-java to v4 and migrate from deprecated 'adopt' distribution
actions/setup-java@v3 is outdated. Update to v4 (currently at v4.8.0, released December 2025). Additionally, the adopt distribution (AdoptOpenJDK) is legacy and has been superseded by Eclipse Temurin. Update to distribution: 'temurin':
- name: Install JDK ${{ env.JAVA_VERSION }}
- uses: actions/setup-java@v3
+ uses: actions/setup-java@v4
with:
java-version: ${{ env.JAVA_VERSION }}
- distribution: 'adopt'
+ distribution: 'temurin'🧰 Tools
🪛 actionlint (1.7.9)
51-51: the runner of "actions/setup-java@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🤖 Prompt for AI Agents
.github/workflows/validate-release.yml around lines 50 to 54: the workflow uses
the deprecated actions/setup-java@v3 and the legacy distribution 'adopt'; update
the action to actions/setup-java@v4 (use the latest v4 release) and change the
distribution value from 'adopt' to 'temurin' so the job installs Eclipse Temurin
JDK; ensure the java-version input remains the same and test the workflow after
updating the action reference.
| if bin/init-store.sh; then | ||
| echo " ✓ Store initialized" | ||
| else | ||
| echo "Error: Failed to initialize store" | ||
| exit 1 | ||
| fi | ||
| sleep ${{ env.SERVER_START_DELAY }} | ||
| if bin/start-hugegraph.sh; then | ||
| echo " ✓ Server started" | ||
| else | ||
| echo "Error: Failed to start server" | ||
| exit 1 | ||
| fi | ||
| popd |
There was a problem hiding this comment.
添加服务器启动命令的超时保护
步骤6和步骤9中的服务器启动命令（bin/start-hugegraph.sh、bin/init-store.sh等）没有超时保护。如果服务器启动失败或挂起，工作流将无限期地等待。
建议为关键的启动命令添加超时：
if bin/init-store.sh; then
echo " ✓ Store initialized"
else
echo "Error: Failed to initialize store"
exit 1
fi
sleep ${{ env.SERVER_START_DELAY }}
- if bin/start-hugegraph.sh; then
+ if timeout 120 bin/start-hugegraph.sh; then
echo " ✓ Server started"
else
echo "Error: Failed to start server"
exit 1
fi同样应在步骤9的二进制服务器启动处应用相同的超时保护（第736行）。
建议将超时值提取为环境变量以便于维护：
env:
# ... existing env vars ...
SERVER_START_DELAY: 3
+ SERVER_START_TIMEOUT: 120
# License Patterns...Also applies to: 604-611, 730-745, 799-805
🤖 Prompt for AI Agents
.github/workflows/validate-release.yml around lines 514 to 530: the start/init
shell commands lack timeout protection causing the workflow to hang if those
scripts block; wrap the calls to bin/init-store.sh and bin/start-hugegraph.sh
with a timeout mechanism (e.g., the timeout utility or a bash timeout wrapper)
so they fail after a configurable period, check the exit code and log a clear
error before exiting the job, extract the timeout value into a reusable
environment variable (e.g., SERVER_CMD_TIMEOUT) at the top of the workflow, and
apply the same change to the other referenced locations (lines 604-611, 730-745,
736, and 799-805) so all critical server startup/init commands use the same
timeout and error handling.
as title.
Summary by CodeRabbit
发布说明
✏️ Tip: You can customize this high-level summary in your review settings.