morningman opened a new pull request, #4063:
URL: https://github.com/apache/doris-website/pull/4063

   Follow-up to #4062. Applying the `add-release` skill to a real release 
(Doris 4.0.8 and Doris Operator 26.0.1) surfaced defects in the skill itself: 
one made the bundled validator impossible to pass, and several sent the release 
manager down avoidable dead ends. This fixes them.
   
   Scope is limited to `doc-tools/skills/add-release/`. No site content changes.
   
   ## Versions
   
   - [ ] dev
   - [ ] 4.x
   - [ ] 3.x
   - [ ] 2.1 or older (not covered by version/language sync gate)
   
   Not applicable — this changes release tooling, not documentation.
   
   ## Languages
   
   - [ ] Chinese
   - [ ] English
   - [ ] Japanese candidate translation needed
   
   Not applicable — same reason.
   
   ## Docs Checklist
   
   - [x] Checked by AI
   - [x] Test Cases Built
   - [x] Updated required version and language counterparts, or explained why 
not
   - [x] If only one language changed, confirmed whether source/translation 
counterparts need sync
   
   ## The validator could not pass
   
   `DORIS_VERSIONS` was asserted to mirror `ALL_VERSIONS` in **both** 
directions. That is not the design:
   
   - `ALL_VERSIONS` is the exhaustive archive, so anything `DORIS_VERSIONS` 
offers must appear there — a real defect if missing.
   - `DORIS_VERSIONS` is a curated shortlist. It carries every patch of the 
current series but only the newest release of older series, and a superseded 
version is sometimes retired deliberately — `4.0.0` was removed in 262c757f46 
when 4.0.1 replaced it.
   
   So every run failed on `4.0.0 is missing from DORIS_VERSIONS`, a failure 
nobody should ever fix; restoring it would put a superseded release back into 
the quick-download selector. The reverse direction is now a warning. The 
version actually being released is still checked against both arrays as a hard 
failure, so the useful check is unchanged.
   
   This adds a `WARN` channel for pre-existing repository state that must not 
block a correct release. Only failures set a nonzero exit code.
   
   ## The binary host was hardcoded, and had already gone stale
   
   Binaries do not come from the Apache mirrors — they come from the CDN named 
by the `ORIGIN` constant in `download.data.ts`. The validator kept its own copy 
of that host, which silently rotted when the host moved (#4062). A second copy 
of a value that already exists in the repository is the bug, not the particular 
value it held.
   
   The host is now read from `ORIGIN`. `--binary-origin` becomes an assertion 
about the expected host — useful when auditing a migration — and its failure 
message now reports what the repository actually declares:
   
   ```
   Binary ORIGIN must match https://download.velodb.io/ 
(src/constant/download.data.ts declares https://download.selectdb.com/)
   ```
   
   ## SKILL.md corrections
   
   - **Doris Operator download data.** The component table said "Usually none". 
Operator releases update `DORIS_OPERATOR_SOURCE_VERSIONS` and 
`DORIS_OPERATOR_BINARY_VERSIONS`; following the old text would have shipped an 
incomplete release.
   - **Where binaries live.** Previously undocumented, so the separate CDN and 
the `ORIGIN` constant had to be rediscovered.
   - **Binaries lagging the source release.** The source tarball is voted and 
published before binaries are uploaded, so finding three source artifacts live 
and nine binaries returning 404 is a normal timing state with no guidance. Adds 
how to tell timing from a filename mistake, what to confirm with the release 
manager, and a reminder to re-check before reporting — during the 4.0.8 work 
the binaries went live mid-task.
   - **`yarn typecheck` cannot run here.** It exhausts memory even at a 12 GB 
heap and reproduces on an unmodified checkout: `tsconfig.json` declares no 
`include`/`exclude` and its own comment says it is not used for compilation. 
Tier 1 stated it flatly. Now records how to confirm the failure is 
environmental and how to get real signal from an isolated typecheck, while 
forbidding a claim that Tier 1 passed.
   - **Discovery recipes** for the release-note issue and the release date, so 
the confirmation gate asks only about what is genuinely unknown.
   - **Ecosystem heading normalization.** Upstream notes are written for 
GitHub; their headings and bare `#507`-style references have to be mapped onto 
the page's conventions while keeping the facts intact.
   
   ## Verification
   
   The validator now reaches a green run against this repository for the first 
time — previously impossible:
   
   ```
   $ node doc-tools/skills/add-release/scripts/validate-release.mjs --component 
doris-core \
       --version 4.0.7 --series 4.0 --source-version 4.0.7 --release-date 
2026-07-12 \
       --position prev --source-dir 
https://dist.apache.org/repos/dist/release/doris/4.0/4.0.7/
   ...
   WARN 4.0.0 is in ALL_VERSIONS but not DORIS_VERSIONS (intentional curation 
or drift? check git history before changing)
   Validated Doris Core 4.0.7: 76 checks passed, 1 warning(s) to review.
   $ echo $?
   0
   ```
   
   Test suite grows from 4 to 7, covering the warning path, origin resolution 
from `download.data.ts`, and `--binary-origin` as an assertion. All 7 pass.
   
   ## Note on overlap with #4062
   
   #4062 swapped the validator's hardcoded host to `download.velodb.io`. This 
PR removes the hardcoded host entirely, so the two touch the same line and 
whichever merges second needs a one-line conflict resolution — keep this PR's 
version, which reads the host from the repository. Happy to drop that hunk from 
#4062 instead if you prefer.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to