Proposing a slight amendment to the `gh api` field docs to clarify the current limitation around "complex" field values, e.g. arrays/objects.
Related: #1484
Signed-off-by: Michael Gasch <mgasch@vmware.com>
The main build script for this project is `script/build.go` which
implements Makefile-like building of the `gh` binary and associated man
pages. Our Makefile defers to the Go script.
However, when setting GOOS, GOARCH, and other environment variables to
modify the target for the resulting binary, these environment variables
would affect the execution of `build.go` as well, which was unintended.
This tweaks our Makefile to reset variables like GOOS and GOARCH when
building the `build.go` script itself, ensuring that the built script
runs on the same platform, and adds the ability to pass environment
variables as arguments to `go run script/build.go`. This allows the
following usage on platforms without `make`:
go run script/build.go GOOS=linux
With this style of invocation, the GOOS setting does not actually affect
`go run` itself; just the `go build` that is executed in a child process.
- Switch to -f/-F instead of -- (this lead to some `gh api` copypasta)
- Remove --json
- Don't parse workflow YAML if not collecting interactively
- Share GetWorkflowContent
- Fix a parsing issue
- With no arguments in TTY mode, prompt which artifacts to download
- Change `--pattern` argument to be just `--name` and only do exact
matching
- For multi-archive downloads, prefix the destination path with the name
of the artifact
- Add tests exercising HTTP functionality
- Avoid "zipslip" path injection when extracting ZIP files
- Add tests for ZIP extraction
