From a4b16b2b0fdbc4b4e1199383a9307e76ef656023 Mon Sep 17 00:00:00 2001 From: jakeross Date: Tue, 18 Aug 2026 15:27:11 -0700 Subject: [PATCH] chore(ci): track staging for the Dagster+ prod code location The workflow triggered on `production`, which is still on 1.2.2 and has no automated_ingestion/ directory, so it would never have fired. Every deploy so far has been a branch deployment from a pull request, leaving the prod code location empty -- which is why Dagster+ sits on "waiting for GitHub Actions build to start". "prod" names the Dagster+ deployment, not this repository's production branch. Tracking staging matches how ocotillo-api-staging already behaves and keeps the location current with where the work is. The original reasoning -- that a pipeline writing to the production database should follow the release flow -- still holds, and the comment now says when to act on it: move the trigger back to `production` in the same change that first points the pipeline at the production database. Until then a deploy publishes code and not data, since the location has neither database nor vendor credentials. Co-Authored-By: Claude Opus 5 --- .github/workflows/CD_dagster_prod.yml | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/.github/workflows/CD_dagster_prod.yml b/.github/workflows/CD_dagster_prod.yml index 1ff7d5de4..edab044d8 100644 --- a/.github/workflows/CD_dagster_prod.yml +++ b/.github/workflows/CD_dagster_prod.yml @@ -1,9 +1,16 @@ # Deploys the `ocotillo-automated-ingestion` code location to the Dagster+ prod # deployment. # -# Triggered on `production`, not `main`: `main` was abandoned in July 2025 and -# the release flow runs feature -> staging -> production (docs/release-flow.md). -# The plan document's reference to `main` predates that being checked. +# "prod" here names the Dagster+ deployment, not the API's `production` branch. +# It tracks `staging`, which is this repository's integration branch and the +# only place `automated_ingestion/` currently exists -- `production` is still on +# 1.2.2 and would never fire. This mirrors how `ocotillo-api-staging` follows +# staging, and keeps the code location current with the work. +# +# Move this to `production` in the same change that first points the pipeline at +# the production database. Until then a deploy here publishes code, not data: +# the location has no database or vendor credentials, so the worst it can do is +# fail to materialize. # # Path-filtered so an ordinary API change does not spend a Dagster+ build. The # filter includes pyproject.toml and uv.lock because the location's dependency @@ -13,7 +20,7 @@ name: CD (Dagster+ prod) on: push: - branches: [production] + branches: [staging] paths: - "automated_ingestion/**" # The code location imports db/ models and domain/ rules in-process,