fix(reset-action): Reset Workshop Data: use the dispatched ref, surface the confirm value

[alukach]

Follow-up to #59. The first real dispatch of Reset Workshop Data failed:

python3: can't open file '.../scripts/fixture_collections.py': [Errno 2] No such file or directory

Run: https://github.com/developmentseed/eoapi-workshop/actions/runs/34893948324

The bug

The workflow was dispatched from the feature branch, but the ref input defaults to main — so actions/checkout replaced the dispatched branch with main, which had neither scripts/fixture_collections.py nor the fixture files it reads.

The mismatch was the design, not the default. A workflow whose logic lives in the repository should not check out a ref other than the one it was dispatched from.

Failing on a missing file was the lucky outcome. The same input pointed at a branch that has the script but is missing a fixture file would have run to completion and deleted that fixture as a leftover — silently, and irreversibly. Concretely: dispatching against main today, before data/tenant-collections.ndjson lands, would delete private-alice-demo and private-bob-demo.

So the ref input is removed rather than given a better default. actions/checkout now uses the dispatched ref, which means the workflow, the script, and data/ always come from the one branch chosen in Use workflow from.

Making the confirmation value discoverable

Separately, finding the string to type into confirm meant knowing to go read the PROJECT variable — a memory test standing in front of an irreversible action.

The dry run now prints it, in both the log and the job summary:

Dry run: nothing deleted.
To delete the 29 collection(s) above, re-run this workflow with
  mode    = apply
  confirm = workshop

Since the intended flow is always dry-run → read the list → apply, the value shows up exactly where the decision is made. Three smaller supports: the input description points at the dry run, the mismatch error now says where the value comes from (the PROJECT variable, and the prefix of every {PROJECT}-*.eoapi.dev hostname), and DEPLOYMENT.md lists all three places to find it.

Verification

Extracted the Reset collections step verbatim from the YAML and ran it against the deployed database in dry-run mode — the actual shipped code path, which is what would have caught the original failure:

• exits 0
• reports 29 non-fixture collections against 2 fixtures
• prints confirm = workshop

Also confirmed the YAML parses, the step is valid bash, the ref input is gone, and Checkout code no longer carries a with: block.

Note for whoever runs it next

Dispatch from a branch that has data/tenant-collections.ndjson — currently feat/stac-auth-proxy-lambda (#49), or main once that merges. From main today the keep-list is only 2 fixtures, and the two private-*-demo collections would be classified as leftovers.

🤖 Generated with Claude Code

https://claude.ai/code/session_01P1CCcrx5fDKuAGsNh8DUFG