You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@magpie.apache.org by "liwenjie200543 (via GitHub)" <gi...@apache.org> on 2026/09/26 07:47:40 UTC
Re: [I] release-verify-rc: validate rc jars [magpie]
liwenjie200543 commented on issue #1173:
URL: https://github.com/apache/magpie/issues/1173#issuecomment-5844373562
I'd like to pick this up. To keep the first PR reviewable, I'd split
the work:
- **PR 1 — blocking checks 1–3, local artifacts only:**
- `.pom` license / `<developers>` / `<scm>` check (check 1)
- podling incubation disclaimer in the POM `<description>` (check 2)
- companion `-sources.jar` / `-javadoc.jar` presence, each with its
own `.asc` and checksums (check 3)
- implemented as a Python tool under `tools/` (stdlib XML parsing,
no new dependencies), with unit tests over fixture POMs and jars,
wired into `release-verify-rc` where the source tree is verified
today.
- **PR 2+ —** the Nexus staging-repository check (4), which needs
network egress and an endpoint contract, then the informational
checks (5–7).
Two questions before I start:
1. Does this slicing order match what you had in mind, or would you
rather see the informational checks first since they never block?
2. For check 4, should the Nexus probe live as a `tools/` adapter with
declared egress (per the framework's egress rules), or be scripted
inline in the skill?
--
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: commits-unsubscribe@magpie.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org