Improve cli

[anbraten]

The woodpecker cli could get some polishing:

• updater Cli updater #3382
  • background update checker
  • update command with --force option
• interactive setup Cli setup command #3384
  • setup command
  • command to enter server-url on first start
  • improved auth (opens browser with UI, send back token to localhost via POST)
• follow step logs when step is still running [CLI] pipeline logs follow logs if still running #1824
• improve error handling for missing args (missing repo id / name results in an parseInt error atm)
• improve outputs Add cli output handlers #3660
  • use table layouts
    • repo list
    • users
• watch options
  • agents list
  • agent tasks
  • pipeline status
• improve exec command
  • support multiple workflow files
  • don't ignore dependencies
  • exec with metadata from UI Allow to download pipline metadata via UI to replay with cli #1155 -> Replay pipeline using cli exec by downloading metadata #4103
  • Supplying secrets to woodpecker-cli exec command #1970
• detect repo from .git/config in pwd [CLI] Get repos from git remotes #910
• add commands
  • orgs (list)
  • agents (list, details, remove)
• [CLI] multiple servers #911
• print that using env vars is possible Improve cli #3386 (comment)

[xoxys]

@woodpecker-ci/maintainers I would like to work on improve error handling for missing args (missing repo id / name results in an parseInt error atm) How do we want to handle it? Do we really want to continue using args? IMO, it would be better to drop args completely and just use flags. Any reason to keep using args?

[anbraten]

I think its quite common practice to use args (see kubectl, docker, ...) therefore I would suggest to stick to it and add an empty-string check with a more descriptive error in front of the parseInt call.

[xoxys]

Obviously, but I could also name a lot of tools without args. We could have a way more clean code without arg validation, as flag validation and required flags is a built-in feature of urfave/cli. However, if args is preferred, that works for me as well.

[lafriks]

I don't know if urfave/cli still checks that required arguments are not empty if required (you can provide argument but provide it with empty value) so check for empty value could still be needed

[xoxys]

There is no required args feature, just a required flags option.

[jinnatar]

While the new setup flow seems nice, it utterly fails on a headless machine. As a quick fix I'd recommend echoing the URL that it's trying to apparently open in a browser or otherwise provide a flow where I can open the URL on another device and feed back a token on the cli.

[qwerty287]

You can easily set URL and token with the WOODPECKER_SERVER and WOODPECKER_TOKEN env vars in these scenarios.

[jinnatar]

You can easily set URL and token with the WOODPECKER_SERVER and WOODPECKER_TOKEN env vars in these scenarios.

The problem is the setup just "stops" when the browser open is attempted behind the scenes. If it was a bit more verbose about it, wouldn't be as confusing.

[qwerty287]

Yes, the log message should print that you can use the env vars. I put it on the list above.

[6543]

yes we should check if the env has an wayland or xorg session, and if not we print out this sugestion and fail as we run "headless" ...