chore: sync modules to v0.8.0 - #43
Conversation
Document gradle as its own type, multi-package-manager autoSetup families, and schema-2 receipts keyed by package-manager token. Co-authored-by: Cursor <cursoragent@cursor.com>
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
YoniMelki
left a comment
YoniMelki
left a comment
There was a problem hiding this comment.
Automated thorough review: 3 findings scored 75/100 across bug-scan, historical-context, and risk-coverage lenses. See inline comments.
| npm: "npm", | ||
| pypi: "pypi", | ||
| maven: "maven", | ||
| gradle: "gradle", |
There was a problem hiding this comment.
Requesting changes: adding gradle as its own governed package type here isn't matched by the vendored jfrog-setup-package-managers skill, which still maps jf setup gradle into the maven key (see skills/jfrog-setup-package-managers/references/workspace-binding.md line 45 and references/global-cache-file.md — both say maven, gradle -> maven and weren't touched by this PR).
Concretely: a user who runs jf setup gradle per the skill's current instructions ends up with repositories.maven written to .jfrog/local/package-resolution.json. But resolver.mjs's workspace overlay assigns straight into SESSION.byType[type] keyed by this new gradle type — so gradle either shows unresolved even after setup, or the write silently clobbers an existing maven binding, depending on ordering.
This only affects the workspace-override path (global admin defaultGlobalRepos config is fine), but it's a real, currently-reachable inconsistency, not a hypothetical. Worth updating the skill's PM->type table in this PR or a paired follow-up before merging.
| typeof data !== "object" || | ||
| data.schemaVersion !== RECEIPT_SCHEMA_VERSION | ||
| ) { | ||
| return emptyReceipt(); |
There was a problem hiding this comment.
Requesting changes: this wipes the entire package-setup.json (every server, every previously-configured package type — not just anything gradle-related) on any schema mismatch, not just the mismatched entries.
Combined with this PR's Option C fan-out in eager-setup.mjs (one job per package-manager-family-member instead of one per type), the very next session for any user with autoSetup on multiple types will re-run jf setup for every family member of every governed+resolved+autoSetup type at once — worst case ~13 jobs vs ~7 pre-upgrade. It's disclosed in the docs and runs backgrounded, so it's not blocking, but it rests entirely on jf setup being a harmless no-op when re-run, which a comment elsewhere in this same file (the TTL section) explicitly flags as not free ("would thrash user-global PM config").
Consider at least logging/surfacing when a full-file wipe happens, so this one-time burst is visible to whoever's debugging a slow or noisy session after upgrade.
| function staleThresholdMs(pmCount) { | ||
| return Math.max(PER_PM_TIMEOUT_MS * Math.max(pmCount, 1), 120_000); | ||
| function staleThresholdMs(packageManagerCount) { | ||
| return Math.max(PER_PACKAGE_MANAGER_TIMEOUT_MS * Math.max(packageManagerCount, 1), 120_000); |
There was a problem hiding this comment.
Requesting changes: this timeout formula is correct, but the worst-case job count it scales with just roughly doubled (7 types -> up to 13 package-manager jobs via Option C's fan-out), so the global lock's stale threshold now maxes out around ~13 minutes instead of ~7.
There's only one global lock file (~/.jfrog/skills-cache/package-setup.lock) serializing jf setup across every session on a machine. When acquireLock() fails, the whole worker exits immediately with no queue and no retry, logged only at DEBUG (invisible by default). On a shared dev box or CI runner with several concurrent agent sessions and autoSetup enabled across multiple types, a session can now silently skip its own zero-touch setup for up to ~13 minutes with no user-visible indication.
Worth either bumping the log level for a lock-contention skip to WARN, or reconsidering whether one global lock (vs. per-server, or per-package-manager) still makes sense now that a single run can span many more jobs.
3 participants
Vendored from
jfrog-agent-hooks/v0.8.0ofJFROG/jfrog-agent-hooks.Updated paths under
.:Also updated:
.github/scripts/sync-modules-vendor.json(source pin + copies manifest).Not included: hooks/hooks.json assembly — verify sessionStart argv wiring separately.
Source: https://github.jfrog.info/JFROG/jfrog-agent-hooks/actions/runs/1201471