Give every CI step explicit resource requests/limits and the default service
account (matching the pre-commit step), so the k8s woodpecker backend schedules
them with bounded resources.
- build/test/lint/package steps: 512Mi/1cpu requests, 2Gi/2cpu limits
- upload step: lighter 128Mi/100m requests, 512Mi/500m limits
Avoid a failed/confusing re-upload by checking whether the package is already
published before PUTting it. artifactapi has no HEAD route (returns 405), so the
guard uses a GET against the served path (RPMs are stored under Packages/): a
200 means it exists and the upload is skipped, anything else proceeds.
Also point at the reachable artifactapi host (artifactapi.k8s.syd1.au.unkin.net,
as used by rpmbuilder) instead of the unresolvable artifactapi3 name.
Publish the plugin as an installable RPM so hosts can drop it into the Vault/
OpenBao plugin directory. On a tag, build the binary, package it with nfpm
(mirroring the rpmbuilder approach), and upload the RPM to artifactapi's local
rpm-internal repository.
- Add packaging/nfpm.yaml installing the binary to /opt/vault-plugins/ plus a
preinstall script that creates the directory
- Add scripts/build-rpm.sh and make rpm / rpm-package targets
- Add .woodpecker/release.yml (event: tag): build -> nfpm package -> PUT to
artifactapi remotes/rpm-internal/files/
Populate the repo with the Vault/OpenBao dynamic secrets engine that mints
LiteLLM virtual keys scoped by model, spending limit, and lease TTL.
- Secrets backend: config, roles, creds paths and a revocable litellm_key type
- LiteLLM API client (generate/update/delete/info) with master-key auth
- Unit tests (mock LiteLLM) and a docker-compose e2e against both Vault and
OpenBao proving the same binary works on each
- Makefile, woodpecker CI (build/test/pre-commit), pre-commit config
unkinben
benvin
gitadmin