This should be fixed in v0.1.3. Action steps now pause instead of auto-skipping, and PipeStep offers to run a local equivalent when one exists. It also parses with: inputs, so setup-node with node-version: 18 actually installs Node 18 in the container. Currently supported: checkout, setup-node, setup-python, setup-go, setup-java, cache, upload/download-artifact. Anything unrecognized gives you a clear pause to run commands manually.

Would genuinely appreciate it if you gave it another shot (pip install --upgrade pipestep) and if you hit anything else, issues on GitHub would be incredibly helpful. The "why did you think I wrote them?" line was exactly the kind of thing I want more of.

PipeStep parses your GitHub Actions YAML, spins up the right Docker container, and gives you a step-through debugger for your run: shell commands.

You can: 1. Pause before each step and inspect the container state. 2. Shell into the running container mid-pipeline (press I). 3. Set breakpoints on specific steps (press B). 4. Retry failed steps or skip past others.

It deliberately does not try to replicate the full GitHub Actions runtime — no secrets, no matrix builds, no uses: action execution. For full local workflow runs, use act. PipeStep is for when things break and you need to figure out why without pushing 10 more commits. Think of it as gdb for your CI pipeline rather than a local GitHub runner.

pip install pipestep (v0.1.2) · Python 3.11+ · MIT · Requires Docker

Would love feedback, especially from people who've hit the same pain point. Known limitations are documented in the README + have some issues in there that I'd love eyeballs on!

Comments URL: https://news.ycombinator.com/item?id=47354008

Points: 12

# Comments: 9

The approach of tracking usage locally and cutting off before you hit billing overages makes a lot more sense than trying to parse the billing API after the fact. Prevention over detection.

Could be cool to set per-worker limits in addition to the global ones.

Storing the reasoning as markdown in git is a clever move. It means the context survives not just across sessions but across team members too. Someone can pick up a task and see why certain approaches were rejected, not just the final code.

Curious if you've found that agents actually read the prior context reliably, or if you need to explicitly inject it at the start of each session.

The frustrating part isn't the outages themselves — it's that the feedback loop for debugging them is so slow. A step fails, you read logs, make a guess, push, wait 5 minutes for the run to get to the same point, and repeat. There's no way to inspect the state of a runner mid-pipeline or retry a single step without re-running the whole workflow.

Reliability issues hurt more when your only debugging tool is "push and pray" (im a recovering vc)

The idea came from the commit-push-wait-read-logs cycle that everyone seems to accept as normal when debugging CI. PipeStep parses your workflow YAML, spins up the right Docker container, and lets you pause before each step, inspect the container, shell in, set breakpoints, skip or retry steps. It deliberately doesn't try to replicate the full Actions runtime — no secrets, no matrix builds, no uses: execution. For that, use act. PipeStep is specifically for when something breaks and you want to figure out why without pushing 10 more commits.

Think of it as gdb for your CI pipeline. pip install pipestep, Python 3.11+, MIT, requires Docker.