[eas-cli] Set up TestFlight internal group when submitting with an existing ascAppId

[tchayen]

Why

I noticed that in some cases when creating apps with CLI I end up in situation where I have to manually go to ASC and add myself as a tester.

How

When running submit, the CLI looks for tester groups. If there are none, it adds the admins. If there are existing groups - it doesn't do anything.

Also changes Expo Go command to use the same path.

Test plan

CI passes.

[github-actions]

Subscribed to pull request

File Patterns	Mentions
packages/eas-cli/**	@douglowder

Generated by CodeMention

Warning: The preamble and epilogue options in commentConfiguration are deprecated. Use template instead.

[codecov]

Codecov Report

❌ Patch coverage is 85.48387% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 63.53%. Comparing base (2a7cb5e) to head (4bde12e).

Files with missing lines	Patch %	Lines
...es/eas-cli/src/submit/ios/ensureTestFlightSetup.ts	89.14%	5 Missing ⚠️
.../credentials/ios/appstore/ensureTestFlightGroup.ts	70.00%	3 Missing ⚠️
packages/eas-cli/src/submit/ios/AppProduce.ts	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4136      +/-   ##
==========================================
+ Coverage   63.39%   63.53%   +0.15%     
==========================================
  Files        1027     1028       +1     
  Lines       46881    46905      +24     
  Branches     9834     9842       +8     
==========================================
+ Hits        29715    29798      +83     
+ Misses      17064    17005      -59     
  Partials      102      102              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

🤖 AI code review

Decision: Ready for human review (with comments)

Overall PR risk: High. The change modifies an existing, widely used path: the iOS submit pipeline now performs App Store Connect authentication and TestFlight group setup whenever a submit profile sets ascAppId, and this runs on eas submit, eas build --auto-submit, and eas submit:internal. The confirmed findings show the removal of the documented EAS_NO_AUTO_TESTFLIGHT_SETUP opt-out leaves eas go, direct eas submit calls in AppProduce.ts, and auto-submit/internal-submit paths with no way to disable automatic group creation and admin invites, and a new auth helper duplicates existing logic that could drift out of sync. Blast radius covers every iOS submission with ascAppId, including CI and worker runs, but rollback is direct since the change is contained to one new module and a small number of call sites.

🟡 Warning (2)

• Removed EAS_NO_AUTO_TESTFLIGHT_SETUP opt-out has no full replacement — packages/eas-cli/src/submit/ios/AppProduce.ts:97 (correctness) · id:9b99a277b299
  Confidence: High — the removed environment variable check and the missing flag check are both confirmed in the traced code paths.
  Impact if shipped: Medium — users who disabled automatic TestFlight setup get beta groups created and Apple admins invited again, on eas go and on eas build --auto-submit/eas submit:internal.
  Suggested remediation: Keep an equivalent global opt-out check inside ensureTestFlightGroupExistsAsync, and also gate the AppProduce.ts call and the go.ts call on ctx.autoTestFlightSetup, or add an explicit flag for go.

  Evidence and reasoning

  Before this PR, ensureTestFlightGroupExistsAsync in packages/eas-cli/src/credentials/ios/appstore/ensureTestFlightGroup.ts checked process.env.EAS_NO_AUTO_TESTFLIGHT_SETUP and returned early when set. This env var was the documented opt-out (CHANGELOG.md, PR [eas-cli] skip creation of testflight group when there are already exisitng testflight groups + allow to opt out of the behavior by setting env var #2856) and applied to every caller, including eas submit and eas go.

  This PR removes that check completely. A repo-wide search shows no remaining reference to EAS_NO_AUTO_TESTFLIGHT_SETUP in packages/eas-cli/src. In its place, eas submit gets a new --auto-testflight-setup/--no-auto-testflight-setup flag, threaded through ctx.autoTestFlightSetup, but only ensureTestFlightSetupForExistingAppAsync reads it.

  Three paths are left with no opt-out:

  1. packages/eas-cli/src/commands/go.ts still calls ensureTestFlightGroupExistsAsync(ascApp) directly, with no flag or env var replacement. A user who ran eas init/eas go with the env var set now has no way to skip TestFlight group creation and admin invites.
  2. packages/eas-cli/src/submit/ios/AppProduce.ts (line 97) calls ensureTestFlightGroupExistsAsync directly and never reads ctx.autoTestFlightSetup. A user running interactive eas submit with no ascAppId hits this path and gets the group created and admins invited even with --no-auto-testflight-setup or the old env var set.
  3. eas build --auto-submit and eas submit:internal build the submission context without setting autoTestFlightSetup, so context.ts defaults it to true, with no flag available to turn it off on these commands.

• Duplicates the existing tryAuthenticateAppStoreWithEasAscApiKeyAsync helper — packages/eas-cli/src/submit/ios/ensureTestFlightSetup.ts:47 (quality) · id:229f49918efd
  Confidence: High — a near-identical helper already exists and is used the same way by a sibling file.
  Impact if shipped: Medium — the two auth-resolution code paths can drift apart over time.
  Suggested remediation: Call tryAuthenticateAppStoreWithEasAscApiKeyAsync(ctx.credentialsCtx, appLookupParams, teamType) instead of re-implementing the env-var/credential-resolution logic.

  Evidence and reasoning

  packages/eas-cli/src/credentials/ios/actions/AscApiKeyUtils.ts exports tryAuthenticateAppStoreWithEasAscApiKeyAsync(ctx, app, teamType). It does the same job: skip if ctx.appStore.authCtx is set, check hasAscEnvVars(), else call resolveAscApiKeyForAppCredentialsAsync, then call ctx.appStore.ensureAuthenticatedAsync. It never throws.

  packages/eas-cli/src/credentials/ios/actions/SetUpProvisioningProfile.ts already calls it this way:

  if (ctx.nonInteractive && !ctx.appStore.authCtx) {
    await tryAuthenticateAppStoreWithEasAscApiKeyAsync(ctx, this.app, this.resolveTeamTypeForAuthentication());
  }
  

  where resolveTeamTypeForAuthentication() uses the same default pattern as the new code.

  The new ensureTestFlightSetupForExistingAppAsync (lines 47-85) reimplements this same sequence by hand: it re-checks hasAscEnvVars(), re-reads the four ASC env vars, and calls ctx.credentialsCtx.appStore.ensureAuthenticatedAsync directly, instead of calling the existing helper with ctx.credentialsCtx (the SubmissionContext.credentialsCtx field is a CredentialsContext, the exact type the helper expects). Now two implementations of the same job exist and must be kept in sync by hand.

---

This review is advisory — it never blocks a merge and never auto-approves.

[szdziedzic]

Can we add flag to disabled this group creation behavior?

[szdziedzic]

awesome

3 small comments

[github-actions]

✅ Thank you for adding the changelog entry!