Fix go-publish argv order and emit git hints on failure#46
Conversation
* Place --version before MODULE_DIR when invoking the Fly CLI. urfave/cli v2 stops flag parsing after the first positional arg, so the previous order silently dropped --version and the CLI fell back to auto-detecting the version from git. That is the failure mode that caused ascii-frog run 499751 (https://github.jfrog.info/JFROG/ascii-frog/actions/runs/499751). * When the CLI reports a git-related failure, emit a `core.notice` hint so users see the remediation even if the red failure summary gets truncated in the GitHub UI: - "not a git repository" -> run `git init && git add -A && git commit`. - "dubious ownership" / "safe.directory" -> add a safe.directory config. * New regression test asserts --version appears before MODULE_DIR in the invocation argv so a future refactor can't reintroduce the ordering bug.
CI's "Verify lib/ is compiled and up to date" check failed because src/go-publish.ts was updated (argv ordering fix + git hint emission) without rebuilding the committed artifact. `npm run build` regenerates only lib/go-publish.js; no other bundles changed.
sverdlov93
left a comment
There was a problem hiding this comment.
🤖 Review comment by Cursor AI
I looked at this PR. I look at a lot of PRs — more than anybody, believe me — and this one is clean. Very, very clean. Tremendous, really.
Reviewed as: GitHub Actions / TypeScript expert
Findings: No issues found.
Test coverage: All new code is tested — argv ordering (explicit index assertion), git-repo hint, dubious-ownership hint, safe.directory variant, negative test for no-hint on generic errors, updated existing test for new argv shape. Comprehensive.
Key observations (no action needed):
core.notice()beforecore.setFailed()ensures hints stay visible even when the failure summary is truncated — smart UX- Independent
ifblocks for both hint types (not if/else) is correct since different error results could trigger both - Graceful degradation with old/new CLI versions is well-designed
Overview
Fixes ascii-frog run 499751, where the
Go Releasejob failed withfailed to resolve version: git log failed: exit status 128even though--version v1.0.428was explicitly passed togo-publish.Root cause: the action was assembling the Fly CLI invocation as
["publish", "go", modulePath, "--version", version]. urfave/cli v2 stops parsing flags after the first positional argument, so--versionwas silently dropped and the CLI fell back to auto-detecting the version from git — which blew up on/tmp/go-release(not a git repo).What changed
Flip the argv order.
--versionis now pushed beforemodulePath, so the CLI actually sees the flag:Emit
core.noticehints when the CLI reports git-related failures, so the remediation stays visible even if the red failure summary gets truncated in the GitHub UI:"not a git repository"→ hint to rungit init && git add -A && git commit -m init."dubious ownership"or"safe.directory"→ hint to rungit config --system --add safe.directory '*'.Regression test asserts
--versionappears beforeMODULE_DIRin the invocation argv so a future refactor can't reintroduce the ordering bug.Flow
flowchart LR Action["go-publish action"] --> ArgsBefore["argv: go MODULE_DIR --version"] ArgsBefore -.->|"urfave/cli drops --version"| Broken["exit 128 on git log"] Action --> ArgsAfter["argv: go --version MODULE_DIR"] ArgsAfter --> CLI["Fly CLI parses --version correctly"] CLI -->|"error"| Hints["Emit core.notice hint for known git classes"] CLI -->|"success"| Publish["Publish artifacts"]Notes
fly-desktop(https://github.com/jfrog/fly-desktop/pull/195) adds CLI-side defense-in-depth:RunCapturehelper,checkGitRepopreflight with hint-rich errors, and a trailing-arg guard that rejectsfly publish go DIR --version Vwith a clear hint — so future callers that get the ordering wrong get the same experience.