Sync from deal-sage/deal-sage@83bb6f4c19
This commit is contained in:
@@ -22,10 +22,36 @@ to every app on its next push, instead of being patched repo by repo.
|
||||
|---|---|---|
|
||||
| Tooling | `scripts/ensure-tools.sh` | curl + jq; AWS CLI only for the S3 upload path |
|
||||
| Manifest | `scripts/manifest.sh` | validates `.dealsage/app.json`, exports `APP_ID`, `CHECKS_JSON` |
|
||||
| Install | (action input) | `npm install --no-audit --no-fund` by default |
|
||||
| Build record | `scripts/start-build.sh` | posts the run to `record-app-build` (commit, branch, author); every later exit closes it with an outcome, so failed runs show in the app hub |
|
||||
| Set up Node.js | `actions/setup-node@v4` | `node-version` input |
|
||||
| Install | `scripts/install.sh` | runs the `install-command` input (`npm install --no-audit --no-fund` by default); a failure closes the run as `build_failed` with the output's tail |
|
||||
| Checks | `scripts/run-checks.sh` | runs each declared check, posts every result to `record-app-check`; a failed **required** check stops here |
|
||||
| Build | `scripts/build.sh` | `npm run build` with `VITE_SUPABASE_URL/ANON_KEY` from org variables; recorded as the `build` check |
|
||||
| Publish | `scripts/publish.sh` | allocate → upload → promote request; DealSage applies the app's publish policy |
|
||||
| Close (no publish) | `scripts/finish-build.sh` | with `skip-publish`, records the run as `checked` |
|
||||
| Report the steps | `scripts/finish-steps.sh` | `if: always()`: settles the step list and closes a run no script closed (see below) |
|
||||
|
||||
### Steps on the build page
|
||||
|
||||
Gitea shows this whole action as a single step of the job, so the scripts
|
||||
report their own steps to `record-app-build` (action `steps`) and the app hub's
|
||||
build page lists them while the run is going: status, duration, a one-line
|
||||
summary and, for a step that failed, the tail of its output. The step list is
|
||||
`PIPELINE_STEPS` in `scripts/lib.sh`, in `action.yml` order (keep the two in
|
||||
step); each script marks its step running when it starts and passed, failed or
|
||||
skipped when it ends (`step_start` / `step_done`; `fail_build` and `die` fail
|
||||
the running step). Set up Node.js is a stock action, so the step before it
|
||||
starts it and the step after it ends it.
|
||||
|
||||
State lives in a file under `$RUNNER_TEMP` that every step of the job shares,
|
||||
so a step that dies still leaves what it wrote. The last step,
|
||||
`finish-steps.sh`, runs whatever happened: a step still running failed, steps
|
||||
that never started were skipped, and if nothing closed the build record (Set
|
||||
up Node.js failed, a script crashed) it closes the run as `failed`, naming the
|
||||
step, instead of leaving it "running" until the hub calls it lost. Reporting is
|
||||
best effort: posts time out after 20 s, and after the first refused post the
|
||||
run stops sending steps; the build itself never waits on or fails because of
|
||||
them.
|
||||
|
||||
The action never decides whether a build goes live. `record-app-version`'s
|
||||
`promote` action does, from the app's `publish_policy` and default branch, and
|
||||
|
||||
Reference in New Issue
Block a user