Offer the Acquia trial signup when the account has no applications

[lauriii]

Note

Stacked PR: this branch is based on acli-create and depends on acquia#2033. The diff shows only the trial-provisioning capability.

Why

acli dev:init (acquia#2033, formerly acli setup) dead-ends for a genuine newcomer: it authenticates and then asks the user to pick an existing application, but a brand-new account has nothing to pick. This PR closes that gap so the one-liner is honest for someone starting from zero.

How applications get created

The public Cloud Platform API is read-only for applications and subscriptions (OPTIONS /api/applications returns allow: GET). Trials are created through the trials service (trials-service-prod.prod.mesh.cicd.acquia.io), which accepts the same OAuth client_credentials tokens as the Cloud API — verified live. Its path prefixes are inconsistent by design and encoded carefully: POST /trials (create) and POST /api/trials/{id} (retry) vs GET /api/trials (current trial, 404 = none) and GET /api/trials/{id} (status poll).

What this adds

acli trials:create (alias trial:create) — the small CLI wrapper + polling loop:

• --site-name, --template (validated against the catalog: archimedes, byte, caresphere, convene, convivial_gov, drupal_cms_starter, haven, healthcare, local, provus_edu, pulse — hard-coded with a @todo, the service has no catalog endpoint yet), --region. All defaulted, so it works non-interactively.
• Safe to re-run: an existing trial is reported (COMPLETED), resumed (in progress), or retried (failed) instead of erroring.
• Honest progress: percent_complete + status printed as they change, a note every minute, timeout after 30 minutes (ACLI_TRIAL_TIMEOUT overrides, validated numeric) with exact resume instructions, and the service's failure_reason surfaced verbatim on failure.

acli dev:init integration — the trial path is reachable three ways, not gated on having existing applications or sites:

• Zero applications: dev:init explains the trial and offers to create one (with a confirm).
• The application picker: every interactive run's list ends with "Create a new application (free 14-day Acquia trial)".
• --new: skips straight to trial creation; works non-interactively.

After trials:create succeeds, dev:init polls GET /applications until the new application appears, waits for a non-production environment with a git URL, and continues the existing flow to a running local site. Re-running acli dev:init resumes naturally at every stage. Zero-apps non-interactive runs do not create a trial implicitly; they fail fast pointing at acli dev:init --new / acli trials:create.

Implementation notes

• CommandBase: pollCloud() (shared backoff poll with testable timeout), and promptChooseEnvironmentConsiderProd() / promptChooseApplication() widened private → protected (one word each) so DevInitCommand reuses the standard choosers; base behavior for other commands is unchanged.
• The trials service token is fetched via the same client_credentials grant the SDK uses, and refreshed once automatically on a 401 mid-poll (provisioning outlives the ~5-minute token lifetime).
• The Salesforce lead endpoint (POST /trials/account, fire-and-forget CRM record) is not called; add later if wanted for parity with the UI.

Verification — live, against the real trials service

Run for real with limited agent credentials (lauri.timmanee+agent@acquia.com):

• Created a real trial: POST /trials → trial 422ba415-dbc8-4830-bd10-1f80a8ce6dfc, then polled its status for the full 15 minutes of server-side provisioning.
• The trial failed server-side — no subscription unit is available for region "us-east-1" (the prod trial pool was empty at test time) — and the command surfaced that reason verbatim with retry guidance.
• Retry verified live: re-running found the failed trial, POST /api/trials/{id} reset it to INITIATED (7% → 14% progress output), and the ACLI_TRIAL_TIMEOUT override + timeout messaging worked.
• Auth (404-not-401 semantics), status polling, and progress output all exercised for real.

Not verified live: a trial reaching COMPLETED (blocked by the empty pool, not by the CLI — the full status object shape including site_url comes from the service's own responses and the Cloud UI fixtures), and therefore the post-trial dev:init continuation against a real new application. Those legs are covered by spec-fixture/mocked tests (TrialsCreateCommandTest, DevInitCommandTest) including the zero-applications, picker, --new, decline, failure, retry, 401-refresh, and timeout paths. A human can finish verification by re-running acli trials:create once the trial pool has capacity, then acli dev:init.

Leftover state from testing: the failed trial above remains on the agent account (no subscription was created; re-running trials:create retries it). The eelaurieskola application was never touched.

Repo checks: phplint, phpcs, phpstan, and the full PHPUnit suite (65 serial + 561 parallel) pass locally.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR enhances acli setup to handle first-time Acquia Cloud users who authenticate successfully but have zero existing applications, by offering a browser hand-off to the Acquia trial signup and then resuming setup once a new application (and a cloneable environment) appears via the Cloud API.

Changes:

• Add a --new flag and a trial-signup + polling flow to create/await a new application when none exist (or when explicitly requested).
• Wait for trial environment provisioning (non-production, non-node, with a git URL) before continuing into the existing setup workflow.
• Expand PHPUnit coverage for the zero-applications path, non-interactive failure modes, and timeout behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
tests/phpunit/src/Commands/App/SetupCommandTest.php	Adds tests for the new trial-signup flow, non-interactive failures, and timeout handling.
src/Command/CommandBase.php	Widens environment-chooser helper visibility to support reuse from the new setup path.
src/Command/App/SetupCommand.php	Implements trial-signup prompting, polling/backoff logic, and environment provisioning waits; adds --new.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.