The bug
Three commands index args[0] without checking that any argument was supplied, and without an Args constraint to reject the empty case. Running them with no identifier panics instead of prompting or reporting an error.
Commands to reproduce
octopus project variables list
octopus project branch list
octopus project-group delete
Outcome
panic: runtime error: index out of range [0] with length 0
goroutine 1 [running]:
github.com/OctopusDeploy/cli/pkg/cmd/project/variables/list.NewCmdList.func1(...)
pkg/cmd/project/variables/list/list.go:75
github.com/spf13/cobra.(*Command).execute(...)
| Command |
Site |
project variables list |
pkg/cmd/project/variables/list/list.go:75 |
project branch list |
pkg/cmd/project/branch/list/list.go:77 |
project-group delete |
pkg/cmd/projectgroup/delete/delete.go:44 |
The first two are the if opts.Project.Value == "" { opts.Project.Value = args[0] } pattern, reached whenever neither -p nor a positional argument is given. The third assigns IdOrName: args[0] unconditionally.
Other commands using the same shape are unaffected because they guard first — target delete, worker delete and workerpool delete all check util.Empty(args), and the */shared/view.go helpers are safe because every caller sets Args: usage.ExactArgs(1).
Related: these commands should prompt, not fail
Once the crash is guarded, the natural behaviour is to prompt rather than error, which is what the rest of the CLI does in interactive mode:
project-group delete already has the prompt — PromptMissing at delete.go:78 selects a project group when IdOrName is empty. It is simply unreachable because the panic happens first. Guarding the argument is the whole fix.
project variables list and project branch list fall through to must supply project identifier, where sibling commands such as tenant variables update offer a selector.
Versions
cli: reproduced on main (25ce4fb)
Octopus Server: N/A — the panic happens during argument handling, before any API call
The bug
Three commands index
args[0]without checking that any argument was supplied, and without anArgsconstraint to reject the empty case. Running them with no identifier panics instead of prompting or reporting an error.Commands to reproduce
Outcome
project variables listpkg/cmd/project/variables/list/list.go:75project branch listpkg/cmd/project/branch/list/list.go:77project-group deletepkg/cmd/projectgroup/delete/delete.go:44The first two are the
if opts.Project.Value == "" { opts.Project.Value = args[0] }pattern, reached whenever neither-pnor a positional argument is given. The third assignsIdOrName: args[0]unconditionally.Other commands using the same shape are unaffected because they guard first —
target delete,worker deleteandworkerpool deleteall checkutil.Empty(args), and the*/shared/view.gohelpers are safe because every caller setsArgs: usage.ExactArgs(1).Related: these commands should prompt, not fail
Once the crash is guarded, the natural behaviour is to prompt rather than error, which is what the rest of the CLI does in interactive mode:
project-group deletealready has the prompt —PromptMissingatdelete.go:78selects a project group whenIdOrNameis empty. It is simply unreachable because the panic happens first. Guarding the argument is the whole fix.project variables listandproject branch listfall through tomust supply project identifier, where sibling commands such astenant variables updateoffer a selector.Versions
cli: reproduced on
main(25ce4fb)Octopus Server: N/A — the panic happens during argument handling, before any API call