# action/cascade-from

Composite Gitea Action that bumps a `FROM <image>:<tag>` line in a target
repo's Dockerfile, then commits and pushes. The target repo's CI fires on
that push, rebuilding against the new base.

The only consumer today is `fritzlab/base` triggering a rebuild of
`fritzlab/runner` whenever the base image changes. This action is the
generalization of that pattern.

## Usage

```yaml
- uses: actions/checkout@v4
- uses: https://code.fritzlab.net/action/image-build@v1
  with:
    image: code.fritzlab.net/fritzlab/base
- uses: https://code.fritzlab.net/action/image-push@v1
  with:
    image: code.fritzlab.net/fritzlab/base
    token: ${{ secrets.CI_BOT_TOKEN }}
    org: fritzlab
    name: base
- uses: https://code.fritzlab.net/action/cascade-from@v1
  with:
    target-repo: fritzlab/runner
    image: code.fritzlab.net/fritzlab/base
    token: ${{ secrets.CI_BOT_TOKEN }}
```

## Inputs

| Name | Required | Default | Description |
|---|---|---|---|
| `target-repo` | yes | — | Target repo to edit (e.g. `fritzlab/runner`). |
| `image` | yes | — | Image to look for in the FROM line. |
| `tag` | no | `github.run_number` | New tag to write into FROM. |
| `file` | no | `Dockerfile` | File inside target-repo to edit. |
| `token` | yes | — | `CI_BOT_TOKEN` with write to target-repo. |
| `host` | no | `code.fritzlab.net` | Gitea host without protocol. |
| `message` | no | `bump <name> to #<tag>` | Commit message override. |

## Behavior

1. Shallow-clone target-repo to a temp dir.
2. `sed -i "s|^FROM <image>:.*|FROM <image>:<tag>|" <file>`.
3. Verify sed actually matched a line — fail if not (catches typos in image
   name).
4. If no diff (target already on this tag): exit 0 silently.
5. Otherwise commit + push to `main` with rebase-on-conflict retry up to
   3 times.

## Notes

- Only matches lines starting with `FROM <image>:` (anchored to start). Multi-stage
  Dockerfiles with a non-anchored `FROM <image>:tag AS stage` will be missed —
  add the AS-aware pattern as a future enhancement if needed.
- Pushing to target-repo triggers its CI, which produces a new image of its
  own. There is no end-to-end orchestration: the upstream repo's CI completes
  the moment cascade-from pushes, regardless of whether the downstream build
  succeeds.