mirror of
https://github.com/hanzoai/deploy.git
synced 2026-10-07 08:44:50 +00:00
zeekayandHanzo Dev
446e343a3d
Two corrections on top of the naming pass, both found by checking the live cluster rather than the source. The rename had silently changed the user-facing annotation key from argocd.argoproj.io/sync-wave to cd.argoproj.io/sync-wave — 63 live Applications carry the old key, so deploying that would have ignored every sync-wave and broken fleet deploy ordering. The key is now cd.hanzo.ai/*, and universe 575650286 moves the ApplicationSet template that stamps it, so the controller regenerates all 63 consistently. The API group in code said argoproj.io/v1alpha1 in 157 places while the cluster has served apps.hanzo.ai/v1alpha1 since 2026-07-23 (the CRDs are applications.apps.hanzo.ai). Code now matches what is actually served. The legacy applications.argoproj.io/app-name label had ZERO live users, so it went with the rest. foo.argoproj.io test fixtures became foo.example.com — arbitrary test domains should not carry a vendor name. go build ./... exit 0. Co-authored-by: Hanzo Dev <[email protected]>
33 lines
1.4 KiB
Markdown
33 lines
1.4 KiB
Markdown
# API Docs
|
|
|
|
You can find the Swagger docs by setting the path to `/swagger-ui` in your Hanzo CD UI. E.g. [http://localhost:8080/swagger-ui](http://localhost:8080/swagger-ui).
|
|
|
|
## Authorization
|
|
|
|
You'll need to authorize your API requests using a bearer token. To get a token:
|
|
|
|
```bash
|
|
$ curl -H "Content-Type: application/json" $CD_SERVER/api/v1/session -d $'{"username":"admin","password":"password"}'
|
|
{"token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE1Njc4MTIzODcsImlzcyI6ImFyZ29jZCIsIm5iZiI6MTU2NzgxMjM4Nywic3ViIjoiYWRtaW4ifQ.ejyTgFxLhuY9mOBtKhcnvobg3QZXJ4_RusN_KIdVwao"}
|
|
```
|
|
|
|
Then pass using the HTTP `Authorization` header, prefixing it with `Bearer `:
|
|
|
|
```bash
|
|
$ curl $CD_SERVER/api/v1/applications -H "Authorization: Bearer $CD_TOKEN"
|
|
{"metadata":{"selfLink":"/apis/apps.hanzo.ai/v1alpha1/namespaces/cd/applications","resourceVersion":"37755"},"items":...}
|
|
```
|
|
|
|
## Services
|
|
|
|
### Applications API
|
|
|
|
#### How to Avoid 403 Errors for Missing Applications
|
|
|
|
All endpoints of the Applications API accept an optional `project` query string parameter. If the parameter
|
|
is specified, and the specified Application does not exist, the API will return a `404` error.
|
|
|
|
Additionally, if the `project` query string parameter is specified and the Application exists but is not in
|
|
the given `project`, the API will return a `403` error. This is to prevent leaking information about the
|
|
existence of Applications to users who do not have access to them.
|