shcizo
41a619b316
Docker Build / docker (push) Successful in 38s
## Summary
- `POST /update` on the master (outside OIDC, bearer `UPDATER_API_KEY`; unset → 503). Matches `image` against `image_repo` on all agents, marks `available_*` on every match, starts webhook-triggered jobs for `auto` services targeting `<image_repo>:<tag>` (followed tag when no tag is given), and waits for them up to `UPDATE_TIMEOUT` (default 5m). 404 on no match, 500 if any auto job failed or timed out, otherwise 200.
- Manual/auto toggle per service on the overview and service page (`POST /services/{id}/mode`, CSRF); auto is blocked for self, `build:` and container services with the reason shown. "Update available" badge and an "Available" row.
- `FinishJob` clears `available_*` only when the successful job was created for that exact ref, after it was reported. Migration `0003_webhook.sql`, phase-3 plan doc, README / gitea-action README / CLAUDE.md / deploy example updated. `action.yml` unchanged.
Closes #8
## Behaviour changes for CI
- Mixed results now return 500 (the old 207 is gone); no match returns 404 instead of 200.
- With a `tag`, Compose services get pinned to `<image_repo>:<tag>` via `compose.override.yaml`; the tag must be a pushed tag.
- `busy` (job already active) and `refused` (not updatable) are reported but return 200.
- The reverse proxy read timeout must exceed `UPDATE_TIMEOUT`.
## Test plan
- [x] `go test ./...` and `go test -race ./internal/agent/... ./internal/master/... ./internal/e2e/`
- [x] `go test -tags integration ./internal/master/store/` against throwaway Postgres
- [x] UI verified in browser (mode toggle, disabled reason, badge via SSE, Available row)
- [ ] Manual: webhook with manual service → `marked` + badge
- [ ] Manual: webhook with auto service → waits, `succeeded`, badge cleared, override pinned
- [ ] Manual: wrong token 401, unknown image 404, offline agent 500
- [ ] Gitea action pointed at the master's `/update` in a real CI run
Reviewed-on: #22
48 lines
2.1 KiB
Markdown
48 lines
2.1 KiB
Markdown
# Deploy via package-updater (composite action)
|
|
|
|
Notifies the `package-updater` master after a CI build. The master records the pushed version on every matching service and, for services in auto mode, updates them and waits for the result.
|
|
|
|
## Usage
|
|
|
|
In a consumer repo's `.gitea/workflows/deploy.yml`:
|
|
|
|
```yaml
|
|
jobs:
|
|
deploy:
|
|
runs-on: ubuntu-latest
|
|
needs: [build-and-push]
|
|
steps:
|
|
- uses: gitea.example.com/shcizo/package-updater/gitea-action@v1
|
|
with:
|
|
endpoint: https://updater.example.com/update
|
|
image: registry.example.com/${{ gitea.repository }}
|
|
tag: ${{ gitea.sha }}
|
|
token: ${{ secrets.UPDATER_TOKEN }}
|
|
```
|
|
|
|
`endpoint` is the master's `/update`, and `UPDATER_TOKEN` is the master's `UPDATER_API_KEY`. It should be set as an organisation-level secret in Gitea so all repos share it.
|
|
|
|
## Inputs
|
|
|
|
| Name | Required | Default | Description |
|
|
|---|---|---|---|
|
|
| `endpoint` | yes | — | Full URL to `/update` |
|
|
| `image` | yes | — | Image reference without tag |
|
|
| `tag` | no | `""` | Tag that was just pushed. Auto services are updated to `<their image repo>:<tag>`, so it must exist in the registry. Omit it to re-pull the tag each service already follows. |
|
|
| `token` | yes | — | Bearer token configured in package-updater |
|
|
|
|
## Failure modes
|
|
|
|
The step exits non-zero on any HTTP 4xx or 5xx. This is intentional: the workflow surfaces the deploy failure to whoever pushed.
|
|
|
|
| Code | Meaning |
|
|
|---|---|
|
|
| `200` | Every match was marked, updated, busy or refused. Manual services are only marked, which is not an error. A service that follows no tag is `refused` when the request has no `tag`. |
|
|
| `401` | Wrong or missing token. |
|
|
| `404` | No service uses the image. Check `image` for typos; matching is case-sensitive. |
|
|
| `500` | At least one auto job failed or timed out (`UPDATE_TIMEOUT` on the master). |
|
|
| `503` | The master has no `UPDATER_API_KEY`. |
|
|
|
|
A request that matches both a working and a failed service now fails as a whole (`500`); the old single-instance updater's `207` no longer exists.
|
|
The master waits for auto jobs, so the request can take minutes; raise any step timeout in your workflow accordingly.
|