Self-hosted acceptance journey
Your instance operator and your team run one journey from the first account to a finished task in each execution mode, and fill in a blank evidence record.
Your instance operator and your administrator run this journey together before live work starts. Run Verify Cognito before go-live first. It must pass.
CodeHerder has two execution modes: process and docker. Docker mode means ch device-server --docker, the trusted mode. Set CH_TRUSTED_EXECUTION=1 to consent. Without it, the device refuses to start. Run the journey once for each mode and host type your install uses. See Administrator briefing for what each mode trusts.
The journey
| # | Step | Expected result |
|---|---|---|
| 1 | The instance operator creates the first account. The operator signs in once through the native pool, or runs ch human bootstrap. |
The instance operator owns the root workspace. A second sign-in by an uninvited person gets signup_closed. The instance operator then adds the operator’s own email to CH_INSTANCE_OPERATORS and restarts the server. |
| 2 | The instance operator invites a person from your team. That person signs in and enters a TOTP code. | The person is a member of the invited workspace. Sign-in asked for MFA. |
| 3 | Your identity provider provisions a second person through SCIM. See SCIM. | The person is a member of the top-level workspace, created by SCIM. |
| 4 | Register one device for each mode and host type you use. For example, a laptop in process mode (ch device-server), a laptop in Docker mode (CH_TRUSTED_EXECUTION=1 ch device-server --docker) or an EC2 host in Docker mode. See Launch a device on AWS. |
Each device shows as online. ch agent placement Builder names it as a device that can take work. ch workspace readiness reports the workspace complete. |
| 5 | On each device, run one story through its workflow. Create it with ch task create. Pin it to the device if needed. See Placement. |
The task moves through plan, code, review, merge and verify to done. The merge request is merged on GitHub or GitLab. |
| 6 | Optional: send one support bundle to your support contact. See Send the bundle. | The support contact confirms that the bundle arrived. |
Evidence record
Fill in one row for each run. Leave a row blank until the evidence exists.
| Step | Mode | Date | Who ran it | Evidence (task ID, merge request link, screenshot path) | Result |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 | (mode, host type) | ||||
| 4 | (mode, host type) | ||||
| 5 | (mode, host type) | ||||
| 5 | (mode, host type) | ||||
| 6 |
When every required row passes, copy the result into the Launch acceptance record.
Related guides
Last updated
