package-updater/gitea-action/README.md

Deploy via package-updater (composite action)

Notifies the package-updater master after a CI build. The master records the pushed version on every matching service and, for services in auto mode, updates them and waits for the result.

Usage

In a consumer repo's .gitea/workflows/deploy.yml:

jobs:
  deploy:
    runs-on: ubuntu-latest
    needs: [build-and-push]
    steps:
      - uses: gitea.example.com/shcizo/package-updater/gitea-action@v1
        with:
          endpoint: https://updater.example.com/update
          image: registry.example.com/${{ gitea.repository }}
          tag: ${{ gitea.sha }}
          token: ${{ secrets.UPDATER_TOKEN }}

endpoint is the master's /update, and UPDATER_TOKEN is the master's UPDATER_API_KEY. It should be set as an organisation-level secret in Gitea so all repos share it.

Inputs

Name	Required	Default	Description
endpoint	yes	—	Full URL to /update
image	yes	—	Image reference without tag
tag	no	""	Tag that was just pushed. Auto services are updated to <their image repo>:<tag>, so it must exist in the registry. Omit it to re-pull the tag each service already follows.
token	yes	—	Bearer token configured in package-updater

Failure modes

The step exits non-zero on any HTTP 4xx or 5xx. This is intentional: the workflow surfaces the deploy failure to whoever pushed.

Code	Meaning
200	Every match was marked, updated, busy or refused. Manual services are only marked, which is not an error.
401	Wrong or missing token.
404	No service uses the image. Check image for typos; matching is case-sensitive.
500	At least one auto job failed or timed out (UPDATE_TIMEOUT on the master).
503	The master has no UPDATER_API_KEY.

A request that matches both a working and a failed service now fails as a whole (500); the old single-instance updater's 207 no longer exists. The master waits for auto jobs, so the request can take minutes; raise any step timeout in your workflow accordingly.