Replaces the old EASYPANEL_WEBHOOK_URL flow with a direct tRPC call to the panel, using three minimal secrets the operator fills in: EASYPANEL_TOKEN - bearer token from EasyPanel profile EASYPANEL_PROJECT_NAME - project name in the dashboard EASYPANEL_SERVICE_NAME - service name inside that project The endpoint (https://panelwebsite.moreminimore.com/api/trpc/services. app.deployService) is hardcoded because the panel URL does not change. Payload uses tRPC's wrapped-json shape: {"json":{"projectName":..., "serviceName":...}}. The build still runs and the dist/ artifact still uploads when any secret is empty — only the trigger step is skipped with a warning. Also adds docs/ci-setup.md explaining the three secrets, the service type requirement (must be 'app' / Dockerfile-based), and a curl recipe for testing the payload shape locally before pushing.
2.2 KiB
CI/CD Setup — EasyPanel Deploy
Push to source-code triggers build-and-deploy.yml:
- Builds the Astro static site into
dist/ - Uploads
dist/as a 7-day artifact - Calls EasyPanel tRPC endpoint to trigger a redeploy
Required Gitea repo secrets
Go to Settings → Actions → Secrets and add three secrets:
| Name | Example | Where to get it |
|---|---|---|
EASYPANEL_TOKEN |
cmq61ao6h000207qn6mmp2i7u |
EasyPanel → profile/settings → API tokens |
EASYPANEL_PROJECT_NAME |
dealplustech-astroreal |
EasyPanel → project name in the dashboard |
EASYPANEL_SERVICE_NAME |
web (or whatever you named the app service) |
EasyPanel → service name inside the project |
If any of these are empty, the workflow logs a warning and skips the deploy trigger. The build still runs and the artifact is still uploaded.
EasyPanel service requirements
The service on the panel side must be:
- Type:
app(Dockerfile-based). The trigger callsservices.app.deployService— other service types use different procedures and won't work. - Source: Git, pointing at this repo (
kunthawat/dealplustech-astroreal) on branchsource-code. - Build command:
npm run build - Output dir:
dist
If you need a different service type later, swap the endpoint in
.gitea/workflows/build-and-deploy.yml to the matching procedure:
services.app.deployService(Dockerfile)services.box.rebuildDockerImage(low-level)services.compose.deployService(docker-compose)
Verifying the trigger payload
If the deploy runs but the panel rejects it, the response in the workflow
log will show the exact zodErrors field telling you which field name
or shape is wrong. Update the PAYLOAD JSON in the workflow accordingly.
To test the payload shape from your local machine:
curl -sS -X POST \
"https://panelwebsite.moreminimore.com/api/trpc/services.app.deployService" \
-H "Authorization: Bearer *** \
-H "Content-Type: application/json" \
-d '{"json":{"projectName":"YOUR_PROJECT","serviceName":"YOUR_SERVICE"}}'
A 2xx response = the panel accepted the trigger. The service will start rebuilding/redploying in the EasyPanel dashboard.