fix(e2e): use a password-policy-compliant admin password in bootstrap

[saifsmailbox98]

Description 📣

The CLI e2e suite started failing at the bootstrap step, admin signup returns 422, so the whole relay/gateway suite fails before any test runs.

Cause: infisical backend #7350 ("enforce shared password policy during signup") now validates the signup password (>=14 chars, at least one letter, at least one number/special, no long repeats, no escape chars). The e2e bootstrap signs up its admin with faker.Password(), which doesn't reliably satisfy that policy, so signup is rejected.

Switches the bootstrap to a fixed password that meets the policy. Not tied to any CLI feature, this affects every CLI PR whose e2e runs against current backend main.

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

Tests 🛠️

# Here's some code block to paste some code snippets

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[infisical-review-police]

💬 Discussion in Slack: #pr-review-cli-334-fix-e2e-use-a-password-policy-compliant-admin-password-in-boot

Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel.

[greptile-apps]

Greptile Summary

This PR fixes the e2e bootstrap step, which was producing 422 errors from the backend's new signup password-policy enforcement. The sole change swaps faker.Password() for a fixed literal that reliably satisfies the new policy.

• The generated email is still randomized via faker.Email(), so parallel CI runs create independent admin accounts and don't interfere with each other.
• The hardcoded password is scoped entirely to test infrastructure and is returned in ProvisionResult for downstream login steps that need it.

Confidence Score: 4/5

Safe to merge — the change is confined to e2e test infrastructure and correctly unblocks the broken bootstrap step.

The fix is minimal and targeted: one literal replaces an unreliable random generator. The randomized email still ensures independent admin accounts across parallel runs, so no test-isolation regression is introduced.

No files require special attention beyond the single-line change in e2e/packages/client/provisioner.go.

Important Files Changed

Filename	Overview
e2e/packages/client/provisioner.go	Replaces faker.Password() with a fixed password that satisfies the backend's stricter signup policy (>=14 chars, letter + number/special). The email remains randomized, so parallel CI runs don't collide.

_{Reviews (1): Last reviewed commit: "fix(e2e): use a password-policy-complian..." | Re-trigger Greptile}

[greptile-apps]

The fixed password is a plain string literal, so if the backend's password policy tightens again (e.g. minimum length increases, or the specific pattern Infisical-E2E-Test1! is flagged by a breach-detection list), there is no way to override it without a code change. An env-var with a policy-compliant fallback keeps the door open for CI overrides without a deploy.

Suggested change

	// Fixed value that satisfies the backend password policy (>=14 chars, letter + number/special);
	// faker.Password() does not reliably meet it.
	password := "Infisical-E2E-Test1!"
	// Fixed value that satisfies the backend password policy (>=14 chars, letter + number/special);
	// faker.Password() does not reliably meet it.
	// Override with E2E_ADMIN_PASSWORD env var if the policy changes again.
	password := "Infisical-E2E-Test1!"
	if envPw := os.Getenv("E2E_ADMIN_PASSWORD"); envPw != "" {
	password = envPw
	}

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!