Z
Zaffre blue Jaguar
Title: DBSchemaApply should resolve changelog from trigger commit SHA, not branch HEAD at runtime
Problem:
DBSchemaApply reads the changelog from the branch HEAD at the time each step executes, not from the commit SHA that triggered the pipeline. In a trunk-based workflow with sequential multi-env promotion (integration → staging → sandbox → prod), this creates a race condition:
  1. User A merges PR → pipeline starts, triggered at commit SHA abc123
  2. Pipeline reaches sandbox stage
  3. User B merges PR → main HEAD advances to def456
  4. Pipeline's prod stage now reads def456 — picking up User B's untested changesets and applying them to prod
Expected Behavior:
DBSchemaApply should snapshot the changelog at <+trigger.commitSha> when the pipeline is triggered, and use that same snapshot consistently across all stages for the lifetime of that pipeline execution — identical to how a git clone at a specific SHA behaves.
Workaround Today:
Use Harness CI with a GitHub connector to clone at the trigger SHA, then invoke the Liquibase CLI directly. This works but forfeits all native DB DevOps features (drift detection, rollback step, audit dashboard, applied changeset expressions).
Ask:
Add a gitRef or commitSha input to DBSchemaApply (defaulting to trigger SHA), so the step resolves the changelog at a pinned ref rather than always reading the live branch HEAD.