CLI pre-submit CI

Start with the shared repo facts in ../_shared/shopify-cli-ci-repo-contracts.md.

Principle

Derive the smallest sufficient pre-submit validation set from the current CI contract. Do not guess, and do not default to the broadest possible local run.

Pattern

1) Classify the diff first

Start by inspecting both the branch diff and the current working tree.

Use one consistent branch-diff command rather than rediscovering it each time.

Example:

git diff --name-only $(git merge-base HEAD origin/main)...HEAD
git status --short

Treat these as different scopes:

• branch diff vs origin/main = what the PR currently changes
• working tree status = what the user might still push next

If the diff clearly maps to a narrow family, keep the investigation narrow.

2) Resolve the contract for the relevant family

Only do this if the diff class suggests a real CI-family mapping, or if the user asks for broader confidence.

Read sources in this order:

1. relevant .github/workflows/*.yml
2. dev.yml
3. package.json
4. helper scripts referenced by those files

For normal PR work, start with .github/workflows/tests-pr.yml.

Read only the files and script sections needed for the diff class you identified. Avoid full reads of large files for docs/config/wiring-only diffs.

3) Map the diff to contract families

4) Finish with staging guidance

After any generator, freshness check, or lightweight sanity pass:

1. inspect git status --short
2. inspect targeted diffs
3. say which files look like:
   • required generated output
   • optional broad churn worth review
   • suspicious changes suggesting the wrong or incomplete generation path

Gotchas

• At PR time, do not automatically run the full workflow-equivalent validation set unless the user asks.
• dev.yml is a useful local entrypoint, but workflow YAML is the source of truth for what CI enforces.
• Broad generated diffs are not automatically wrong; distinguish required churn from suspicious churn.
• Do not stop at “run this command.” Explain what likely needs staging.
• If the diff is docs/config/wiring only, do not escalate to heavyweight checks unless the workflow or the user gives a reason.
• For docs/config/wiring-only diffs, avoid full reads of large workflow or script files unless the diff clearly maps to an enforced CI family.
• If the change touches async/timing-heavy tests, local servers, callback flows, socket teardown, or workflow topology, warn that CI-only failures may still appear even after local checks pass.

Examples

• "What should I run before I push this PR?" → derive the minimal checks from workflow → dev.yml → package.json, then recommend focused tests plus any required generators.
• "Submit this PR." → treat it as a pre-submit moment, suggest the minimal recommended checks and likely staging requirements first, and ask before running them.
• "Which generated files do I need to commit?" → reproduce the relevant generation path, inspect git status, and separate required generated output from optional churn.
• "I changed a command flag; what repo checks matter?" → start from the freshness job that enforces command-surface updates rather than from memory.