Add network_logs_options input (capture network log content for XCUITest)

[aditya711-code]

What

Adds a network_logs_options step input that mirrors the App Automate networkLogsOptions capability, so XCUITest builds on BrowserStack App Automate can capture the content (request and response bodies) of network logs — not just metadata such as URLs, headers, latency and status codes.

Until now the step exposed only a network_logs on/off toggle, so capture-content could be enabled on local/IDE runs but not when running through this Bitrise step.

Usage

- network_logs_options: '{"captureContent": true}'

The value is the same JSON you would pass as the networkLogsOptions capability elsewhere, so it maps 1:1 from local/IDE configurations.

Behavior

• The input is parsed as JSON and forwarded as networkLogsOptions in the build payload.
• Providing it automatically enables network_logs, because networkLogsOptions is only honoured when network logs are enabled (a notice is logged when this happens).
• When empty/omitted, the payload is unchanged — networkLogsOptions is omitted entirely — so the change is fully backward compatible.
• Invalid JSON produces a clear, actionable error.

Changes

File	Change
step.yml	New network_logs_options JSON input under "Debug logs"
structs.go	NetworkLogsOptions struct + *NetworkLogsOptions field (omitempty) on the payload
util_fns.go	parseNetworkLogsOptions helper + wiring in createBuildPayload()
constants.go	Actionable error string for invalid JSON
main_test.go	Unit tests for parsing and payload shape
README.md	Documented the new input

Testing

• gofmt, go build ./..., go vet ./..., go test ./... all pass.
• New unit tests cover input parsing (valid {"captureContent": true/false}, empty, malformed JSON, wrong value type) and payload shape (provided → networkLogs:true + networkLogsOptions.captureContent:true; empty → networkLogsOptions absent).

Ref: AAP-20051

🤖 Generated with Claude Code

[darshilgada24]

Claude Code PR Review

PR: #13 • Head: 7a2e7af • Reviewers: stack:pr-review

Summary

Adds a network_logs_options JSON input to the Bitrise XCUITest step, mirroring the App Automate networkLogsOptions capability ({"captureContent": true} → capture request/response bodies). Parsed via a new parseNetworkLogsOptions, surfaced as a *NetworkLogsOptions pointer on the payload (omitempty, so existing builds serialize unchanged), and auto-enables networkLogs when options are supplied.

Review Table

Priority	Category	Check	Status	Notes
High	Security	No hardcoded secrets or credentials	Pass	None.
High	Security	Authentication/authorization checks present	N/A	Client step; uses existing BStack creds.
High	Security	Input validation and sanitization	Pass	Empty→nil; malformed/typed-wrong JSON → hard failf with actionable message.
High	Security	No IDOR — resource ownership validated	N/A	—
High	Security	No SQL injection (parameterized queries)	N/A	—
High	Correctness	Logic is correct, handles edge cases	Pass	Empty/true/false/malformed/wrong-type all handled and tested. Compiles — strings/encoding/json/fmt/log already imported in util_fns.go, failf defined.
High	Correctness	Error handling is explicit, no swallowed exceptions	Pass	Parse error → failf (fatal); no silent swallow.
High	Correctness	No race conditions or concurrency issues	N/A	—
Medium	Testing	New code has corresponding tests	Pass	TestParseNetworkLogsOptions (5 cases) + TestCreateBuildPayloadNetworkLogsOptions (force-enable + omission).
Medium	Testing	Error paths and edge cases tested	Pass	Malformed JSON + wrong value type asserted to error with network_logs_options in message.
Medium	Testing	Existing tests still pass (no regressions)	Pass (not executed)	Change is additive + omitempty; could not run go test locally (no Go toolchain on the review host).
Medium	Performance	No N+1 queries or unbounded data fetching	N/A	—
Medium	Performance	Long-running tasks use background jobs	N/A	—
Medium	Quality	Follows existing codebase patterns	Pass	Mirrors the existing use_test_sharding JSON-input pattern; struct tag + pointer/omitempty idiomatic.
Medium	Quality	Changes are focused (single concern)	Pass	Scoped to the one input.
Low	Quality	Meaningful names, no dead code	Pass	—
Low	Quality	Comments explain why, not what	Pass	Good rationale comments on parse + auto-enable.
Low	Quality	No unnecessary dependencies added	Pass	stdlib only.

Findings

• File: util_fns.go:108 (parseNetworkLogsOptions)

• Severity: Low

• Reviewer: stack:pr-review

• Issue: json.Unmarshal ignores unknown fields, so a typo'd or wrong-case key (e.g. {"capturecontent": true} or {"capture_content": true}) parses successfully with CaptureContent defaulting to false — yet networkLogs is still force-enabled because options != nil. The user gets network logs without content and no signal that their option was misspelled.

• Suggestion: Decode with dec := json.NewDecoder(strings.NewReader(raw)); dec.DisallowUnknownFields() so a bad key produces the same actionable network_logs_options error the malformed-JSON path already returns.

• File: util_fns.go:154 (createBuildPayload)

• Severity: Low

• Reviewer: stack:pr-review

• Issue: Supplying {"captureContent": false} sets options != nil, which force-enables networkLogs even if the user explicitly set network_logs=false — i.e. an explicit "no content" request silently turns network logs on. This is consistent with the documented "enabling this auto-enables Network logs," so it's non-blocking, just slightly surprising for the false case.

• Suggestion: Either only auto-enable when CaptureContent is true, or leave as-is (documented) — reviewer's call.

Platform note (non-blocking): this is a pass-through of the networkLogsOptions.captureContent capability; it assumes the App Automate backend accepts that exact shape for XCUITest builds. Worth a one-line confirmation against the backend capability handling, but not a code issue in this repo.

---

Verdict: PASS — Additive, backward-compatible (pointer + omitempty), well-tested, and it compiles. Both findings are Low/advisory.