mirror of
https://github.com/hanzoai/deploy.git
synced 2026-10-07 08:44:50 +00:00
The fork was already ours everywhere that matters — our image, our IAM (dex is not deployed), hanzo kv behind what the env still called REDIS. Only the vocabulary was upstream's: ARGOCD_* across the Go, the manifests, the docs and the plugin contract, and mkdocs still titled 'Argo CD' pointing at argoproj/argo-cd. ARGOCD_ -> CD_ and REDIS_ -> KV_ across 345 files, plus the 8 e2e/cmp fixtures that assert the plugin env contract — those had to move with the binary, which now emits CD_APP_NAME where they expected ARGOCD_APP_NAME. Left alone deliberately, because renaming them would be wrong: - util/helm/testdata/redis/ and gitops-engine/.../statefulset*.yaml are fixtures for a THIRD-PARTY chart named redis, not our config - util/kustomize/testdata/ likewise - generated.proto regenerates from types.go, which is already clean go build ./... exit 0. LOCKSTEP: the live StatefulSet sets 47 ARGOCD_* names the binary no longer reads. universe 4a5375735 carries the matching manifest change; they deploy together or the controller falls back to defaults. Co-authored-by: Hanzo Dev <[email protected]>
1.4 KiB
1.4 KiB
API Docs
You can find the Swagger docs by setting the path to /swagger-ui in your Argo CD UI. E.g. http://localhost:8080/swagger-ui.
Authorization
You'll need to authorize your API requests using a bearer token. To get a token:
$ 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 :
$ curl $CD_SERVER/api/v1/applications -H "Authorization: Bearer $CD_TOKEN"
{"metadata":{"selfLink":"/apis/argoproj.io/v1alpha1/namespaces/argocd/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.