bitflicker64 commented on code in PR #3326:
URL: https://github.com/apache/hugegraph/pull/3326#discussion_r4277809830


##########
docs/ci.md:
##########
@@ -142,3 +142,67 @@ Each separate job or matrix item requests a runner; steps 
within a job share one
 but [plan-dependent total and macOS concurrency 
limits](https://docs.github.com/en/actions/reference/limits#job-concurrency-limits-for-github-hosted-runners)
 still apply. Reducing job allocations and long executions lowers shared-pool 
demand;
 it does not guarantee a specific queue delay.
+
+## Dependency baseline
+
+The separate [dependency submission 
workflow](../.github/workflows/submit-dependencies.yml)
+installs the complete reactor with Java 17 in a `contents: read` job, then 
generates
+each module's resolved graph with Ferstl 4.0.3. The repository's
+[stdlib serializer](../.github/scripts/dependency-snapshot.py) preserves the
+[official Maven parser 
6.0.1](https://github.com/actions/maven-dependency-submission-action/tree/1f666f7ac2ab7b72cd5e22eaf7f23c8a581db1db)
+package URLs and relationships. Non-test scopes take precedence when Ferstl 
merges
+scopes onto one artifact; only test-only artifacts are development 
dependencies.
+Every tracked POM must have a graph; empty aggregator manifests are allowed, 
but a
+completely empty inventory fails. It runs on master pushes or manual
+dispatches. Only `apache/hugegraph` (not a fork) and the explicitly allowed
+`hugegraph/hugegraph` test fork on `refs/heads/master` can run the submission 
job,
+which alone has `contents: write`. PRs, other repositories and other refs 
cannot
+run the writer. Maven inherits no submission token, and checkout does not 
persist
+credentials. An independent `contents: read` job resolves all module dependency
+scopes with Apache Maven Dependency Plugin 3.8.1 `tree` JSON. Its
+[stdlib inventory adapter](../.github/scripts/dependency-inventory.py) records 
each POM's
+package URLs, scopes and direct/indirect relationships independently of the 
Ferstl
+parser. The writer requires exact equality with that inventory, including empty
+aggregators; a graph retaining one direct package while omitting another fails.
+The global runtime/shipped jar filename inventory has a different scope and 
does
+not replace this per-module check.
+
+A pinned `actions/upload-artifact` transfers `snapshot.json` and 
`inventory.json`
+as separate artifacts. The fresh writer runner uses fixed inline stdlib Python 
to
+verify both successful producer jobs and both artifact/run/attempt/SHA 
identities
+before downloading. It bounds ZIP and JSON sizes, checks each archive digest,
+and reads only its one expected regular JSON member in memory. Duplicate 
members,
+paths and symlinks fail; no archive members are extracted to disk. A signed 
storage
+redirect is fetched without forwarding GitHub Authorization, and further 
redirects
+are refused. The writer does not check out the repository, run Maven, or 
execute
+downloaded code. The first-party upload action is permitted by the
+[ASF Actions policy](https://infra.apache.org/github-actions-policy.html).
+
+Checkout and snapshot use the event commit SHA. Master is checked before 
install
+and again after generation in both read-only jobs; a stale run fails. The 
writer
+checks the run attempt, successful producer, artifact ID/name, JSON schema,
+detector/correlator and source SHA/ref. It verifies all manifest paths against 
the
+event commit's source tree, rejects empty or mismatched inventory, and checks 
master
+immediately before and after submission. Snapshots retain the checked event SHA
+if master advances during submission; that run fails its final freshness check.
+
+If submission fails, use **Re-run all jobs** or start a fresh 
`workflow_dispatch`
+on master. **Re-run failed jobs** keeps the older generation artifact, which 
the
+writer rejects because both reports must be produced in the same run attempt.
+
+A fixed master-only correlator keeps successive baseline snapshots in the
+same stream within each repository; ASF and org inventories are independent. 
The writer's
+identity is separate from automatic PR submissions so they cannot replace its 
baseline.
+The [snapshot 
API](https://docs.github.com/en/rest/dependency-graph/dependency-submission#create-a-snapshot-of-dependencies-for-a-repository)
+requires Contents write permission. The writer also has Actions read permission
+to verify run and artifact metadata. Snapshot metadata identifies the 
repository
+adapter rather than claiming that the combined generation/submission action 
ran.
+
+This producer supplements the existing dependency review and shipped-inventory
+checks without changing their severity, license rules or inventory. Merging the

Review Comment:
   Minor: a pull request opened or pushed while the baseline run for the 
current master tip is still going fails dependency review. `docs/ci.md` does 
not say that a re-run fixes it.
   
   Evidence: `dependency-review` compares against `pull_request.base.sha`, 
which is the master tip at the time of the PR event, not the branch's merge 
base. This head's run shows it: the job checked out "Merge a75e16be into 
4b77b7bcb" and asked for base SHA 4b77b7bcb, the tip at that moment, while this 
branch forks from 06f90a9f. A baseline for a new tip exists only after 
`generate`, `inventory` and `submit` all finish, and each producer first runs a 
full reactor `mvn install` (4m24s on its own in this PR's `dependency-check` 
job). `check-dependencies.yml` calls `actions/dependency-review-action@v5` 
without `retry-on-snapshot-warnings`, so inside that window the action sees 0 
base snapshots, treats every dependency as added and fails on the critical 
`[email protected]` advisory. Job 116115771998 logged exactly that. A later 
re-run of the job passes this check, because a re-run reuses the same base SHA 
and that SHA has a baseline by then (unless it was skipped, which is the line 88
  thread).
   
   Requested change: add a sentence to this section saying that a 
`dependency-review` failure that reports 0 base snapshots soon after a master 
merge should be re-run once the Dependency baseline run for that master SHA has 
succeeded. If waiting in CI is preferred, `check-dependencies.yml` could set 
`retry-on-snapshot-warnings: true` with a `retry-on-snapshot-warnings-timeout` 
long enough to cover one baseline run (the default is 120 seconds), at the cost 
of holding a runner while it waits.



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