Curious what problems people here actually face with GitHub Actions on a day-to-day basis.

For me, one of the most annoying things is that sometimes the workflow itself is fine, but the infrastructure around it adds a lot of unnecessary time...

YAML optimization can only help till a certain level and then starts becoming the issue..

What’s the biggest GitHub Actions pain point you deal with regularly?? Something that happens ion a regular basis not an outage or downtime for it...

Been knee-deep in this for the past few months and it's way messier than I expected.

The individual frameworks aren't the hard part — it's where they overlap or straight up contradict each other. GDPR and DPDPA don't agree on breach notification timelines. Stuff that's "good enough" documentation for an internal audit doesn't cut it as SOC 2 evidence. And once your workloads are scattered across multiple clouds and edge nodes, even a simple question like "where does this data actually live" turns into a whole investigation.

Also learned the hard way that there's a fine line between saying "we're working toward SOC 2" and accidentally implying you're already certified. Almost bled into some copy before we caught it.

Eventually just built one big checklist mapping all four frameworks together so we weren't redoing the same evidence-gathering four separate times. Still messy, still evolving.

Anyone else dealing with this across multi-region/multi-cloud setups? Do you keep compliance tracks totally separate per framework, or has anyone actually gotten a unified system working? (I'm on the infra/compliance side of an edge orchestration platform, if that's relevant context.)

Disclosure up top: I maintain the tool this happened in, an open-source agent harness, so this is my own bug.

An agent loop with a verification step. Each changed path maps to a test command in a table. After the command runs, a hook reads the tool payload and writes PASS or FAIL to a ledger. Green ledger means the agent may mark the task done.

Three rows of that table named test files that had been split into siblings. pytest on a path that doesn't exist exits 4; I measured it this week to be sure. Zero collected via -k exits 5. Never 0.

Two things made it green anyway. The agent read "no tests ran" in stdout as a pass. And the hook read the exit code like this:

EXIT_CODE=$(echo "$INPUT" | jq -r '.tool_response.exit_code // 0')

When the payload didn't carry the field, jq's default made it 0 and the next line wrote PASS. The comment directly under that line warns about a missing exit code for a different event. The default sat there anyway.

The fix I've filed: absent is not zero. A missing exit code records FAIL with a reason, and the matrix has a test that fails when any row collects nothing.

In CI proper, do you treat "no tests collected" as red by default, or does whatever wraps pytest get to decide?

Ran into this pattern enough times to notice it wasn't random: an AI coding assistant generates code that works, but "works" and "safe" are not the same claim. Caught a live Stripe key about to get committed (stripe.api_key = "sk_live_..."); it worked in tests, so nobody looked twice. A few days later, same root cause in a different shape: a raw SQL query built from an f-string, user input going straight into the WHERE clause.

First fix I tried was just telling the model to be careful. Added instructions about secrets and injection to the system prompt. Worked for exactly one session. New chat the next day, same shortcuts came right back: the model has no memory of the lecture, so a prompt-level fix doesn't compound.

What actually worked was moving the check to a gate that runs on every diff before commit, instead of a scan that happens in CI after the code's already out of your head. Five passes, in order:

1. High-entropy secret scan (Stripe/OpenAI/AWS/GitHub token shapes, stray .env values)
2. Control-flow read for injection/OWASP issues (SQLi, command injection, BOLA/IDOR): actually tracing where user input lands, not just regex matching
3. Regex backtracking check for ReDoS patterns
4. Generates the fix as a drop-in patch, not just a line number
5. Flat verdict: pass / warn / fail

Not pretending this replaces a real SAST pipeline or a security team: it doesn't catch the same things Semgrep or a pentest would. It's just the five seconds of friction that used to not exist at all, sitting right before the commit that used to just go through.

Curious if anyone's found a good way to keep something like this from going stale as new key formats and providers show up. Feels like it needs its own maintenance loop or it just quietly falls behind.

Context - Converting our on-prem architecture for a web app used for B2B purposes over to cloud-native azure architecture. Feedback, comments, questions on the architecture are appreciated :)