Skip to content

[product-manager-impersonator] Transactional rollback for quick-setup.sh failures #1028

Description

@github-actions

Feature Idea

Summary: Add failure-safe rollback to scripts/quick-setup.sh so setup errors don’t leave users on a new branch with partially written workflow files.

Why a Customer Would Want This

Teams use quick setup as the fastest onboarding path, but a mid-run failure currently leaves manual cleanup work (branch state + partial files). A transactional rollback would make first-run adoption safer and less frustrating.

Rough Implementation Sketch

  • Track initial branch and files created during execution (the script already collects created_files).
  • Add a trap-based failure handler that, on error, removes newly created files and checks out the original branch.
  • Add an opt-out flag (for example --keep-partial) for users who want to inspect partial state.
  • Document rollback behavior in quick-setup docs/help text.

Why It Won't Be That Hard

This is a localized Bash change in one script plus small docs updates. The script already has the key state needed (created_files and deterministic branch switch point), so rollback is mostly wiring cleanup into existing flow.

Evidence

  • scripts/quick-setup.sh exits immediately on command failure (set -euo pipefail) without cleanup today (scripts/quick-setup.sh:9).
  • It switches/creates the setup branch before downloading workflow files (scripts/quick-setup.sh:173-183).
  • It writes multiple workflow files incrementally (scripts/quick-setup.sh:194-213).
  • It already tracks created files in-memory (created_files at scripts/quick-setup.sh:186, appends at :202 and :212).
  • Quick setup is positioned as the recommended install path in docs (README.md:28-39, gh-agent-workflows/README.md:44-55).

Note

🔒 Integrity filter blocked 40 items

The following items were blocked because they don't meet the GitHub integrity level.

  • #937 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #1025 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #1024 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #1010 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #359 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #850 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #851 search_pull_requests: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #505 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #476 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #704 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #694 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #684 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #875 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #676 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #139 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • #472 search_issues: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".
  • ... and 24 more items

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

What is this? | From workflow: Trigger Product Manager Impersonator

Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions