bug(actions): duplicate `artifacts` command registered on the same parent shadows `actions artifacts <run-id>` #291

New issue

Closed

opened 2026-07-20 08:22:55 +00:00 by hexajon · 0 comments

hexajon commented

2026-07-20 08:22:55 +00:00

(Migrated from codeberg.org)

Summary

Two distinct cobra commands named artifacts are registered on the same parent (actions). Cobra does not reject duplicate names - Find() returns the first match - so one of them is unreachable from the CLI.

Evidence (at `13aceba2`)

Both call Cmd.AddCommand on the same actions parent:

internal/cmd/actions/artifacts.go:21 - ArtifactsCmd, Use: "artifacts", Short: "Repository artifact operations". A group with list / get / delete / download subcommands. Registered at internal/cmd/actions/artifacts.go:112.
internal/cmd/actions/workflows.go:158 - artifactsCmd, Use: "artifacts <run-id>", Short: "List artifacts for a workflow run", Args: cobra.ExactArgs(1). Registered at internal/cmd/actions/workflows.go:184.

Symptom

madtea actions --help lists artifacts twice, with the two different Short strings, which is how this surfaced.

Since Go initializes files within a package in lexical filename order, artifacts.go runs before workflows.go, so the group registers first and should win lookup. That would make the per-run listing (actions artifacts <run-id>, backed by svc.ActionsWorkflows.ListRunArtifacts) unreachable: the run-id positional would instead be parsed as an unknown subcommand of the group. Worth confirming against the intended precedence rather than taking the init-order reasoning as settled.

Suggested direction

Whichever way precedence is meant to fall, the two want distinct paths. One option is folding the per-run listing into the group as a subcommand that takes the run id, e.g. actions artifacts run <run-id>, leaving actions artifacts list as the repository-wide listing. That keeps both reachable and makes the repo-vs-run scope distinction explicit at the call site.

A guard that fails the build (or a test) on duplicate command names under one parent would catch the class - this is silent today.

Notes

Found while updating a v0.12.3 CLI reference doc against v0.18.0. Not verified at runtime: the CLI declines to run under an agent and redirects to the madt_* MCP tools, so the above is a source read plus the doubled --help output, not an executed repro.

## Summary Two distinct cobra commands named `artifacts` are registered on the same parent (`actions`). Cobra does not reject duplicate names - `Find()` returns the first match - so one of them is unreachable from the CLI. ## Evidence (at 13aceba2) Both call `Cmd.AddCommand` on the same `actions` parent: - `internal/cmd/actions/artifacts.go:21` - `ArtifactsCmd`, `Use: "artifacts"`, `Short: "Repository artifact operations"`. A group with `list` / `get` / `delete` / `download` subcommands. Registered at `internal/cmd/actions/artifacts.go:112`. - `internal/cmd/actions/workflows.go:158` - `artifactsCmd`, `Use: "artifacts <run-id>"`, `Short: "List artifacts for a workflow run"`, `Args: cobra.ExactArgs(1)`. Registered at `internal/cmd/actions/workflows.go:184`. ## Symptom `madtea actions --help` lists `artifacts` twice, with the two different `Short` strings, which is how this surfaced. Since Go initializes files within a package in lexical filename order, `artifacts.go` runs before `workflows.go`, so the group registers first and should win lookup. That would make the per-run listing (`actions artifacts <run-id>`, backed by `svc.ActionsWorkflows.ListRunArtifacts`) unreachable: the run-id positional would instead be parsed as an unknown subcommand of the group. Worth confirming against the intended precedence rather than taking the init-order reasoning as settled. ## Suggested direction Whichever way precedence is meant to fall, the two want distinct paths. One option is folding the per-run listing into the group as a subcommand that takes the run id, e.g. `actions artifacts run <run-id>`, leaving `actions artifacts list` as the repository-wide listing. That keeps both reachable and makes the repo-vs-run scope distinction explicit at the call site. A guard that fails the build (or a test) on duplicate command names under one parent would catch the class - this is silent today. ## Notes Found while updating a v0.12.3 CLI reference doc against v0.18.0. Not verified at runtime: the CLI declines to run under an agent and redirects to the `madt_*` MCP tools, so the above is a source read plus the doubled `--help` output, not an executed repro.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

sixfold-space/madtea#291

No description provided.

Rows
Columns

bug(actions): duplicate artifacts command registered on the same parent shadows actions artifacts <run-id> #291