[improvement](release) Improve release helper workflow

[morningman]

What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary: The release helper scripts covered packaging and vote preparation, but the workflow did not include a completion step for publishing a passed release candidate, and the README was not structured enough for a release manager or AI agent to turn a version such as Doris 4.0.7 into concrete next steps. This PR adds a release completion script, updates the release configuration for final SVN artifact paths, and rewrites the README as a step-by-step runbook with clear boundaries for source artifacts, convenience binaries, manual emails, and PMC-only release SVN publishing.

Release note

None

Check List (For Author)

• Test: No need to test (release tooling and documentation only)
  • Manual test: git diff --check upstream-apache/master..HEAD
  • Manual test: bash -n tools/release-tools/01-check-env.sh tools/release-tools/02-package-sign-upload.sh tools/release-tools/03-vote-mail.sh tools/release-tools/04-release-complete.sh
• Behavior changed: No
• Does this need documentation: No

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[morningman]

skip buildall

[morningman]

/review

[github-actions]

Automated review found one blocking issue in the release completion tooling.

Critical checkpoint conclusions:

• Goal/test: The PR adds a step-04 release completion script and rewrites the release-tool runbook. The script is syntactically valid, but the final published checksum sidecar is not verifier-compatible after the artifact rename.
• Scope: The change is focused on release helper scripts and documentation.
• Concurrency/lifecycle: No Doris runtime concurrency, lock, lifecycle, or static-initialization behavior is involved.
• Configuration: release.env propagates the new final artifact basename and release SVN directory into step 04; the checksum bug is in how the existing step-02 sidecar is reused after that basename change.
• Compatibility: Release artifact consumers expect .sha512 files to verify beside the published tarball. The accepted inline issue covers the incompatible checksum content.
• Parallel paths: The vote upload path and completion path were both checked; the issue is at their boundary.
• Testing: bash -n passes for all release-tool scripts. CI is otherwise green except this pending review job. I could not run an end-to-end SVN publish because svnmucc is not installed in this runner and the public SVN mutation must not be exercised during review.
• Observability, transactions, and data writes: No Doris service observability or transaction path is involved. The public SVN write is intentionally atomic via svnmucc, but it would publish an invalid checksum sidecar as written.
• Performance: No performance issue found.
• User focus: No additional user-provided review focus was supplied.

Subagent conclusions: OPT-1 was accepted as MAIN-1 and submitted as the inline comment below. TSC-1 duplicated the same checksum issue and was merged. The remaining checked points were dismissed with evidence in the shared ledger. Convergence round 2 ended with both optimizer-rewrite and tests-session-config reporting NO_NEW_VALUABLE_FINDINGS for the final ledger/comment set.

[github-actions]

The final checksum sidecar still contains the RC filename. Step 02 writes ${PKG_BASE}.tar.gz.sha512 with sha512sum "$f", so the file content names apache-doris-${TAG}-src.tar.gz. Here step 04 only renames that sidecar to ${dst_tar}.sha512 while moving the tarball to apache-doris-${VERSION}-src.tar.gz and removing the dev RC folder. A normal sha512sum --check apache-doris-${VERSION}-src.tar.gz.sha512 in the release directory will then look for the old RC tarball name and fail. Please regenerate or rewrite the checksum content for ${dst_tar} before publishing it, and verify the final sidecar against the final basename.

[morningman]

/review

[morningman]

skip buildall

dismiss

[github-actions]

I found two release-tooling issues that should be fixed before this workflow is relied on for a real release.

Critical checkpoint conclusions:

• Goal: add a release-completion step and runbook for publishing a passed RC. The overall shape is clear, but step 04 does not yet prove the published bytes are the voted RC before regenerating the final checksum.
• Scope/focus: the change is focused on release tooling and docs; no FE/BE/cloud runtime path, concurrency, storage format, transaction, or config-propagation concern applies.
• Parallel paths: step 01 is the readiness gate for the release workflow, but it was not updated for the new step-04 svnmucc dependency.
• Tests: bash -n and the new checksum test pass locally, but the test currently covers the final checksum filename rewrite and misses the voted-RC sidecar validation gap and the step-01 dependency check.
• Existing review context: the earlier checksum-sidecar thread is not duplicated here; it covered the final sidecar retaining the RC filename, while the new inline comment covers validating the source artifacts before regenerating that sidecar.

Subagent conclusions:

• optimizer-rewrite found no optimizer/rewrite-specific candidates for this release-tooling PR.
• tests-session-config reported TSC-1, merged into MAIN-1, and TSC-2, accepted as MAIN-2.
• Convergence round 1 ended with both live subagents replying NO_NEW_VALUABLE_FINDINGS for the same final ledger/comment set.

Validation performed: bash -n tools/release-tools/01-check-env.sh tools/release-tools/02-package-sign-upload.sh tools/release-tools/03-vote-mail.sh tools/release-tools/04-release-complete.sh tools/release-tools/tests/test-release-complete-checksum.sh; bash tools/release-tools/tests/test-release-complete-checksum.sh. The checkout is grafted/shallow and thirdparty/installed is absent, so no full Doris build was attempted; this PR is release tooling only.

[github-actions]

Step 04 should verify the tarball bytes it is about to publish against the checksum and signature sidecars that voters approved before generating the RC-free checksum. Right now ${src_asc} and ${src_sha512} are only checked with svn info; the script then svn cats ${src_tar} and writes a new ${dst_sha512} from those bytes. If the dev SVN tarball was corrupted or replaced after the vote while the original sidecars remained, this path would publish the changed bytes and create a matching final checksum, so the release SVN artifacts would no longer be proven to be the voted RC. Please fetch ${src_sha512} and ${src_asc} into checksum_dir, verify the downloaded ${PKG_BASE}.tar.gz with sha512sum --check and gpg --verify, and only then rewrite/regenerate the final sidecar with ${dst_tar}.

[github-actions]

Since step 04 now requires svnmucc, please add it to the required-tool loop in 01-check-env.sh as well. The README tells release managers to run ./01-check-env.sh before the release flow and lists svnmucc as a prerequisite, but that script still checks only git gpg svn sha512sum curl gzip. Without this, an RM can get environment looks READY, publish the RC vote, and only discover after the vote passes that the release-completion tool is unavailable.

dismiss

[morningman]

/review

[morningman]

skip buildall

[github-actions]

I found one remaining release-tooling issue on the current head, separate from the already-open checksum/signature validation thread.

Critical checkpoint conclusions:

• Goal: the PR adds a release-completion step and rewrites the runbook. The overall flow is clear, but the new step 04 still has one path-default bug that can target the wrong release SVN hierarchy.
• Scope/focus: this change is limited to tools/release-tools; no FE/BE/cloud runtime, optimizer, transaction, storage, concurrency, or persistence path applies.
• Parallel/config paths: step 01 now checks svnmucc, and the final checksum filename regeneration is covered by a shell test. The script fallback for RELEASE_SVN_DIR does not match release.env or the README.
• Existing review context: I did not duplicate the existing line-164 thread about validating the tarball against the voted .sha512 and .asc sidecars. The older svnmucc preflight and final checksum filename comments are addressed by the current patch.
• Tests/validation: bash -n passed for the changed scripts/tests, both added shell tests passed, and shellcheck -e SC2250 passed for the new step 04 script and tests. The checkout is shallow/grafted and lacks thirdparty/installed; real svn/svnmucc clients are also unavailable here, so I could not run a full Doris build or exercise the actual SVN commit.

Subagent conclusions:

• optimizer-rewrite found no optimizer/Nereids issues and recorded the line-164 sidecar validation concern as a duplicate of existing thread discussion_r3565719663.
• tests-session-config proposed TSC-1, which I verified and accepted as inline comment MAIN-1.
• Convergence round 1 ended with both live subagents replying NO_NEW_VALUABLE_FINDINGS for the same final ledger/comment set.

User focus: no additional user-provided review focus was supplied.

[github-actions]

This fallback does not match the release SVN layout that the new release.env and README document. If RELEASE_SVN_DIR is unset or empty in a custom/older env, step 04 falls back to ${RELEASE_SVN_BASE}/${VERSION}; for 4.0.7 that publishes under release/doris/4.0.7 instead of the intended release/doris/4.0/4.0.7. Please derive RELEASE_SERIES="${RELEASE_SERIES:-${VERSION%.*}}" here and use ${RELEASE_SVN_BASE}/${RELEASE_SERIES}/${VERSION} for the fallback, or fail when RELEASE_SVN_DIR is missing so the script cannot silently target the wrong release directory.