[GayatriNairAtBrowserstack]

Update (0016fe1): go.mod directive raised to go 1.27.3, so stacks on Go 1.27.0-1.27.2 also switch to a patched toolchain. Re-verified with go1.27.3: go build, go vet, go test ./... pass; binary reports go1.27.3. Figures below are from the earlier 1.26.10 run; the auto-switch / fail-closed behaviour is the same with 1.27.3 as the floor.

Jira: https://browserstack.atlassian.net/browse/AAP-22022

Why

Go releases before 1.26.10 / 1.27.3 do not distrust the 8 compromised eMudhra intermediate keys. This step runs on customer CI and sends BrowserStack credentials to api-cloud.browserstack.com, so its TLS client must come from a patched toolchain. go.mod was go 1.18.

What

• go.mod: go 1.18 -> go 1.26.10. A toolchain go1.26.10 line was added, but go mod tidy removes it because it matches the go line, so it adds nothing.
• go mod tidy: marks tablewriter / testify as direct deps and drops the unused stretchr/objx from go.sum. No dependency version changes.
• failf(err.Error()) -> failf("%s", err.Error()) at 6 call sites (main.go x5, util_fns.go x1). go vet's printf check covers non-constant format strings for modules declaring go >= 1.24, so without this go test fails at vet. It also stops a % in an error message being read as a format verb.
• No io/ioutil migration: ioutil.ReadAll is deprecated but still compiles, and vet does not flag it. Left unchanged to keep the diff small.

How customers get go1.26.10

This step has no prebuilt executable in the steplib, so the Bitrise CLI Go toolkit (stepman toolkits/golang.go) builds it from source on the customer's stack:

• It uses go from PATH if that Go is >= 1.22.12. Otherwise it installs Go 1.22.12.
• It runs go build with GOROOT=<that go>, GO111MODULE=on and no GOTOOLCHAIN override.
• With the default GOTOOLCHAIN=auto, Go >= 1.21 reads go 1.26.10 and downloads and builds with go1.26.10.

step.yml has no field for the Go version (toolkit.go has only package_name), so no step.yml change is needed.

Caveats:

• A stack whose Go is 1.27.0-1.27.2 already satisfies go 1.26.10, so the toolchain does not switch and the build still uses an unpatched compiler. Closing that gap would need go 1.27.3 instead.
• If a stack sets GOTOOLCHAIN=local or blocks proxy.golang.org, builds on Go older than 1.26.10 now fail with go.mod requires go >= 1.26.10. They do not silently build with the vulnerable toolchain.

Build / test (local, darwin/arm64)

$ GOTOOLCHAIN=go1.26.10 go version
go version go1.26.10 darwin/arm64
$ go build ./...            # ok
$ go vet ./...              # ok
$ go test -count=1 -v ./...
--- PASS: TestUpload (0.00s)
--- PASS: TestCheckBuildStatus (1.84s)
--- PASS: TestGetDevices (0.00s)
--- PASS: TestParseNetworkLogsOptions (0.00s)
--- PASS: TestCreateBuildPayloadNetworkLogsOptions (0.00s)
ok  	github.com/browserstack/browserstack-bitrise-espresso-step	3.243s
$ go version -m <binary>
<binary>: go1.26.10

Simulated Bitrise toolkit build: Homebrew go1.26.4 binary, GOROOT set to the go1.26.4 root, GO111MODULE=on, GOTOOLCHAIN unset. Resulting binary reports go1.26.10.
With GOTOOLCHAIN=go1.26.4 forced: go: go.mod requires go >= 1.26.10 (running go 1.26.4; GOTOOLCHAIN=go1.26.4).

Before the change (go 1.18 directive, local go1.26.4), build, vet and test all passed.

Release steps still needed (not done in this PR)

1. Merge, then tag a new step version (e.g. 1.1.0). The steplib entry is steps/browserstack-bitrise-espresso-step/ in bitrise-io/bitrise-steplib.
2. Open a steplib PR via bitrise run share-this-step. Note: bitrise.yml sets BITRISE_STEP_ID: espresso-browserstack-official and BITRISE_STEP_VERSION: 1.0.0, but the steplib ID is browserstack-bitrise-espresso-step. Fix both before sharing.
3. The steplib has only 1.0.0, pinned to commit 180c566 from 2022. Customers on browserstack-bitrise-espresso-step@1 get this fix only once the new version is published.
4. Tell customers who reference the step via git::...@<ref> to update the ref.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Central YAML (base), Organization UI (inherited), Workspace UI (inherited)
• Review profile: ASSERTIVE
• Plan: Enterprise
• Run ID: 6c828bff-d68e-496a-8c1e-21247dc839a2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}