Added basic clap CLI with subcommand stubs#5
Conversation
| enum Command { | ||
| /// List the Rust project repos | ||
| ListRepos, | ||
| /// Download workflow files for a repo | ||
| Fetch { | ||
| /// Repo in the form owner/name | ||
| repo: String, | ||
| }, | ||
| /// Run zizmor on a repo's cached workflows | ||
| Analyze { | ||
| /// Repo in the form owner/name | ||
| repo: String, | ||
| }, | ||
| /// List, fetch, and analyze every repo | ||
| Run, |
There was a problem hiding this comment.
I think the only subcommand I agree we need to get started is analyze.
Thinking as someone using the CLI, I see example invocations like
crabwatch analyze rust-lang # org inferred from input parsing
crabwatch analyze --org rust-lang
crabwatch analyze rust-lang/team # repo inferred from input parsing
crabwatch analyze --repo rust-lang/team
crabwatch analyze --repo rust-lang/team --check ci-security # only check with zizmor
crabwatch analyze --org rust-lang --check dependency-updates # dependabot / renovate in-place?
crabwatch analyze --repo rust-lang/team --check <some-other-check-we-may-add-later>
# etcThose are examples, and I think there is room to discuss the CLI design in an upcoming PR, or perhaps a follow-up issue.
Afaict, analyze would handle under the hood the functionalities you defined as subcommands, ie, listing repos in the Github org (when needed), downloading them (when needed), and everything else on demand.
Does that make sense to you?
There was a problem hiding this comment.
Makes sense. I went with four subcommands because that's how the task
description listed the steps. but getting started with just analyze is cleaner.
there are a few things I want to confirm before reworking this PR:
- Should
--checktake multiple values, or one at a time with all checks
by default if omitted? - For inputs, do you want both positional (
crabwatch analyze rust-lang)
and flagged (--org rust-lang), or just one? - For the org-level case, should we filter to repos with
crabwatch = true
(the property from Add custom properties team#2512), or analyze the whole org?
I'll update this PR once we settle these.
There was a problem hiding this comment.
Should --check take multiple values, or one at a time with all checks by default if omitted?
In this case, I'd assume all as the default value if omitted
For inputs, do you want both positional (crabwatch analyze rust-lang) and flagged (--org rust-lang), or just one?
In general I'd prefer either one of them, but not both of them, for the sake of conciseness if for some reason I have to support more subcommands with more arguments. I think the implementation with flagged arguments might be a bit easier with clap.
For the org-level case, should we filter to repos with crabwatch = true (the property from rust-lang/team#2512), or analyze the whole org?
We should support both in crabwatch, but the ruleset most likely will invoke this CLI passing in the name of repo the associated Github Actions Workflow is running.
Supporting the whole organization is important for us as maintainers, since we can summarize data collected from all the repos in the output, gathering statistics, etc
There was a problem hiding this comment.
The CLI is now a single analyze command to start with .
A few small notes on what's in the commit:
--repoand--orguseclap::ArgGroupso exactly one is required
and they can't be combined--checkis optional. Omitting it means run all checks- The CLI doesn't check the
crabwatch = trueproperty.--orgscans
every repo in the org
2 participants
Adds the basic CLI using clap. The four commands (
list-repos, fetch, analyze, run) just print a placeholder for now. Shared flags for verbose, cache directory, and GitHub token are in place.Each will get real code in a follow-up PR.