Add --format argument to application commands

[ehl-jf]

Summary

Adds a --format flag to all AppTrust mutating commands so users can choose between
human-readable table output and JSON output suitable for scripting. When the flag is
omitted, no response body is printed — commands continue to emit their existing
log.Info "...successfully" confirmation, preserving pre-flag behavior. Supported
formats are advertised via SupportedFormats so the CLI framework auto-completes
the flag.

Commands updated

The following commands now accept --format=table|json:

• app-create, app-update
• version-create, version-promote, version-release, version-update, version-update-sources, version-rollback
• package-bind

Implementation notes

• New helpers in apptrust/common/output.go:
  • PrintResponse(data, format, writer, orderedKeys) — dispatches to JSON pretty-print
    or table rendering based on the requested format, writing to the caller-supplied
    io.Writer. None (no --format) is a no-op.
  • PrintTable(data, writer, orderedKeys) — renders the response body as a
    FIELD/VALUE table using text/tabwriter, honoring orderedKeys to control row
    order and skipping empty/nil fields. Non-scalar values (arrays, objects) are
    JSON-marshalled so they render as proper JSON rather than Go syntax. Returns early
    when the response body is empty.
• Service layer signatures updated: applications, versions, and packages
  services now return []byte response bodies (previously discarded) so commands can
  format and print them. Mocks regenerated accordingly.
• Ordered key lists:
  • Shared in apptrust/common/keys.go: OrderedAppVersionKeys (used by
    version-create, version-update, version-update-sources) and OrderedAppKeys
    (used by app-create, app-update).
  • Per-command for the unique cases: version-promote, version-release,
    version-rollback, package-bind — each defines its own ordered<Cmd>Keys at
    the top of the file.

---

• The pull request is targeting the main branch.
• The code has been validated to compile successfully by running go vet ./....
• The code has been formatted properly using go fmt ./....
• All static analysis checks passed.
• All tests have passed. If this feature is not already covered by the tests, new tests have been added.
• All E2E tests have passed.
• All changes are detailed at the description.

---

[shayshim]

apptrust/common/output_test.go line 16 — TestPrintJsonOrTableResponse_JSON doesn't assert on any output

This test passes but asserts nothing about the JSON output. The Json branch writes via log.Output, not the buf writer — so buf is always empty and never read. The only assertions are NoError (always passes) and that the hardcoded sampleOutputJSON constant is valid JSON (trivially true).

Consider capturing log.Output to assert the JSON was actually printed correctly.

[shayshim]

Duplicate ordered*Keys slices

Several ordered*Keys slices are identical and could be shared within their package:

• orderedCreateAppKeys and orderedUpdateAppKeys are byte-for-byte the same
• orderedCreateAppVersionKeys, orderedUpdateAppVersionKeys, and orderedUpdateAppVersionSourcesKeys are all identical

Since they live in the same package, a single shared variable would avoid silent drift if the response shape changes and only some copies get updated.

[shayshim]

apptrust/common/output.go line 44 — fmt.Sprintf("%v", val) renders arrays and objects as Go syntax

val comes from json.Unmarshal into map[string]interface{}, so its runtime type depends on the JSON value:

• Strings, numbers, booleans render correctly with %v
• Arrays render as [elem1 elem2] instead of ["elem1","elem2"]
• Objects render as map[key:value] instead of {"key":"value"}

The current orderedKeys only list scalar fields so this doesn't bite today, but the API response is untyped []byte — there's no guard against a future key pointing to a nested value. Safer alternative:

b, err := json.Marshal(val)
if err != nil {
    return err
}
strVal := string(b)

[shayshim]

go.mod — Direct JFrog dependencies pinned to unreleased commits

Three direct JFrog dependencies are pinned to pseudo-versions (unreleased commits):

• build-info-go v1.13.1-0.20260429070557-93b98034d295
• jfrog-cli-core/v2 v2.60.1-0.20260504054219-ba16d20c7b0f
• jfrog-client-go v1.55.1-0.20251223101502-1a13a993b0c7

These commits could be force-pushed or may depend on unreleased APIs. Please pin to tagged releases before merging to main.

[ehl-jf]

@shayshim

Regarding

• build-info-go v1.13.1-0.20260429070557-93b98034d295
• jfrog-cli-core/v2 v2.60.1-0.20260504054219-ba16d20c7b0f
• jfrog-client-go v1.55.1-0.20251223101502-1a13a993b0c7

Those are not released anymore, instead for the CLI uses directly the master commit, only the CLI is released.
And push force are disabled for main branches.

[ehl-jf]

@shayshim I took care of your remarks, let me know if anything else needs to be done.

[SaharBracha]

Make sure to run e2e test - https://github.com/jfrog/jfrog-cli-application/actions/workflows/e2e-tests.yml

[SaharBracha]

Run go fmt