feat(action): post /update to every endpoint in a fleet, continuing past failures

gitea-action/README.md

@@ -14,7 +14,10 @@ jobs:
     steps:
       - uses: gitea.example.com/shcizo/package-updater/gitea-action@v1
         with:
-          endpoint: https://updater.example.com/update
+          endpoint: |
+            https://updater-swarm.example.com/update
+            https://updater-web01.example.com/update
+            https://updater-web02.example.com/update
           image: registry.example.com/${{ gitea.repository }}
           tag: ${{ gitea.sha }}
           token: ${{ secrets.UPDATER_TOKEN }}
@@ -22,15 +25,24 @@ jobs:
 
 `UPDATER_TOKEN` should be set as an organisation-level secret in Gitea so all repos share it.
 
+All instances in the fleet must share the same bearer token, since one `token`
+input is sent to every endpoint.
+
 ## Inputs
 
 | Name | Required | Default | Description |
 |---|---|---|---|
-| `endpoint` | yes | — | Full URL to `/update` |
+| `endpoint` | yes | — | Full URL to `/update`. Several may be given, one per line, to update a fleet. |
 | `image` | yes | — | Image reference without tag |
 | `tag` | no | `""` | Tag that was just pushed (logged for audit) |
 | `token` | yes | — | Bearer token configured in package-updater |
 
 ## Failure modes
 
-The step exits non-zero if `package-updater` returns HTTP 4xx or 5xx. This is intentional — the workflow surfaces the deploy failure to whoever pushed.
+Every endpoint is attempted, even when an earlier one fails — otherwise one dead
+server would leave the rest of the fleet un-updated, and the CI log would not show
+which hosts actually succeeded.
+
+The step exits non-zero if any endpoint returned 4xx/5xx or was unreachable. The
+log lists each endpoint with its HTTP status and response body, so a partial
+deploy is visible at a glance.