# app-delivery integration

`auto-oncall-services` follows the same production deployment shape as the
existing ops services:

1. GitHub Actions in this repository builds a Docker image.
2. The image is pushed to ECR.
3. The workflow dispatches `tidbcloud/app-delivery` workflow
   `bump-ops-server-version.yaml`.
4. app-delivery updates the image tag in the target kustomization.
5. ArgoCD syncs the target Kubernetes cluster.

## Target Environments

| Environment | ECR repository | app-delivery path | Kubernetes cluster | Namespace |
|-|-|-|-|-|
| staging auxiliary jobs | `aisupport/staging/auto-oncall-services` | `staging/devops-service/auto-oncall-services/envs/staging` | `devops-staging` | `auto-oncall-services-staging` |
| Agent9 main staging | `aisupport/staging/auto-oncall-services` | `staging/devops-service/auto-oncall-services-agent9/envs/staging` | `devops-staging` | `auto-oncall-services-agent9` |

The Agent9 deployment is the active main auto-oncall target. It has its own
ApplicationSet, namespace, ConfigMap, Secret, Service, and Deployment. The manual
`deploy-auto-oncall-services-agent9-staging.yml` workflow builds one image,
publishes the same checked-in `skills/` packages to Agent9, advances the linked
Agent's exact Skill pins, and bumps both staging applications. Wetech OP remains
disabled independently of Skill publication.

The auxiliary staging application is still required: it schedules the Recent
Optimizer and Codex-history cleanup and owns their ConfigMap and PVCs. It must
not render the retired legacy `auto-oncall-services` Deployment or Service.
The Agent9 main application is the only long-running AOS API and automation
owner.

The legacy prod AOS runtime and app-delivery registration are retired. There is
no prod build/deploy workflow and no AOS workload, service, PVC, ConfigMap, or
credential Secret to recreate there. The retained optimizer/Focus observer
manifest owns the `auto-oncall-services-prod` namespace together with its
read-only ServiceAccount, Role, and RoleBinding.

## Required app-delivery changes

Before the staging workflow can complete rollout, app-delivery needs:

- `.github/workflows/bump-ops-server-version.yaml` to accept
  `auto-oncall-services` as a valid `devops-service` application.
- The app-delivery files staged in this directory copied into the same relative
  paths in the app-delivery repository. Syncing the prod target removes any
  legacy AOS registration and manifests instead of copying a runtime template.

The app-delivery `newName` values should point to:

- staging: `552185537300.dkr.ecr.us-west-2.amazonaws.com/aisupport/staging/auto-oncall-services`

The `newTag` is rewritten by `bump-ops-server-version.yaml` to the Git commit
SHA produced by the deploy workflow.

## First staging rollout order

For the first staging rollout, avoid merging an app-delivery ApplicationSet
that still points at `newTag: REPLACE_ME`.

Recommended order:

1. Merge the `auto-oncall-services` code and GitHub Actions workflows in this
   repository.
2. Run the staging or prod deploy workflow once. It will build and push the image
   tagged with the commit SHA.
3. Use that image tag in the initial app-delivery PR, or let
   `bump-ops-server-version.yaml` update the `newTag` before enabling the
   ApplicationSet.
4. Merge the app-delivery PR so ArgoCD syncs a real image tag.