The feature branch is shared with GitLab and deliberately carries no .gitea/ directory, so merging it removed docker-publish.yml from develop and would have stopped the sandbox image builds. Restore it unchanged from 2320b41.
Changelog: other
This repository is built by the shared ds.gitlab-ci.yml template; carrying a second CI system alongside it invited the reader to wonder which one is authoritative. The Gitea Actions workflow that builds both images stays in the sandbox Gitea mirror, which is where the sandbox images are produced.
The README, the pipes payload values and the sandbox values no longer point at a file this repository does not contain.
Changelog: removed
The GitLab project was seeded with a scaffold (CODEOWNERS, LICENSE, README, pipeline.variables.sh) unrelated to the local history, so this is an unrelated-histories merge. Kept GitLab's CODEOWNERS - it names the real codeowners group - along with its LICENSE wording and PROJECT_VERSION_NUMBER=0.0.1. Kept the local README, which documents the service rather than GitLab's default template.
The Gitea workflow now derives the registry owner from github.repository_owner instead of hard-coding a personal namespace.
Changelog: added
Adapted from template-code-location's docker-publish.yml. The repository ships two images, so the workflow builds the code location from the root Dockerfile and the payload from payload/Dockerfile, and tags both with the same short SHA - that shared tag is what keeps a code location and the payload it dispatches on the same version.
Each image gets its own gate before it is pushed. The code location image must load its Dagster definitions and carry payload/work.py for the subprocess transport. The payload image must contain dagster_pipes and must not contain dagster, which is readiness checklist L11; running that assertion against the code location image fails as expected, so the check discriminates rather than passing vacuously.
Changelog: added
