GitHub push-to-deploy connects one repository to one Answer Cloud site. The site's plan must include GitHub integration, and your GitHub account must grant the Answer Cloud app access to the intended repository.
1. Connect the repository account#
Ask your agent to call github_get_connection for the selected organization. If the connection is absent, open the returned install_url in your browser and authorize the GitHub account and repositories you want to expose. Then have the agent inspect the connection again.
Choose the repository deliberately. Granting the app access and linking the repository are separate steps; neither substitutes for verifying the selected Answer Cloud site.
2. Select the build mode#
| Mode | Repository contents | Deployment behavior |
|---|---|---|
actions |
Editable Astro or other build source | GitHub Actions builds the site and uploads the output using OIDC |
none |
Already compiled static output | Answer Cloud deploys the linked branch directly without a build job |
Use actions for a normal Astro project. Link with github_link_repo, supplying site_slug, repository as owner/name, branch, and any source/output directories. The default branch is taken from the repository when none is specified. One repository cannot power several linked sites.
A source subdirectory and output directory are distinct settings: a monorepo might build within website/ and publish its dist/ output. Verify the returned configuration instead of assuming the repository root is the artifact.
none), the dashboard shows direct push-to-deploy controls.3. Install the generated workflow#
For Actions mode, write the returned workflow to .github/workflows/answercloud.yml, review it, and commit and push through your normal repository process. The generated workflow uses id-token: write and contents: read for short-lived OIDC deployment access, so no long-lived deployment secret needs to be copied into GitHub.
If the workflow cannot be committed because GitHub returns a permission error, inspect the app or token's workflow-write permission. Contents access alone may not permit changing .github/workflows/.
With the release workflow active, automated uploads default to staging. Confirm the release configuration before pushing a change you expect to reach production. Use promotion after review when appropriate.
Automatic commits after uploads#
With GitHub enabled and a repository linked, successful uploads through start_deploy / finalize_deploy or deploy_files also save public deployed files to the linked branch. This applies to staging, production, and deployments targeting both. Saving runs after publication, so the site can be live before its commit appears.
For build: none, files are saved under dir; for actions, under output_dir beneath dir. The commit contains deployed output, including generated public files. Preserve the editable source project separately from that output. Private CMS templates and GitHub workflow files are excluded.
Changed output files are updated, obsolete files tracked by the preceding save are removed, and unrelated repository files are preserved. Unchanged output reuses the existing commit. GitHub-originated deployments already have a commit and are not saved again. Automatic saves skip Actions builds and their own push webhook, so they do not create another deployment.
Deploy history and the git result from get_deploy and list_deploys show the completed commit. Filter list_deploys with its full commit_sha to find a deployment by the saved commit. Temporary GitHub errors retry automatically. If saving ultimately fails, the site stays live and receives github_commit_failed. Check the GitHub connection and repository access, then deploy again.
4. Verify the actual commit#
After the push, inspect the Actions run for Actions mode, then use list_deploys and get_deploy. Compare the deployment's git metadata with the commit you intended and verify the public result.
For build: none, the GitHub commit check is named answer.cloud; for Actions mode, inspect the Actions job status.
For build: none, github_trigger_deploy can deploy the linked branch head without another push. It does not build Actions sites; rerun their GitHub workflow instead.
github_unlink_repo stops push-to-deploy and automatic deployment commits while preserving the current live site. Manual deployment remains available. See the GitHub tool reference for arguments and errors.