Hey everyone 👋
So, we finally made the big leap last quarter: migrated our entire monorepo (about 15 microservices, a few Terraform stacks, and the frontend) from CircleCI to GitHub Actions. Overall, the developer experience is fantastic, and the tight integration is a win. However, we've hit a **major snag with job concurrency** that's causing us some serious pipeline pain and I'm wondering if anyone else has battled this particular dragon.
In CircleCI, we heavily relied on their `concurrency` key at the workflow level to limit runs, especially for our main branch. We'd set it to something like `concurrency: main-deployments` to ensure only one deployment pipeline could run at a time, preventing race conditions in our staging environment. It was simple and rock-solid.
In GitHub Actions, the concurrency model feels... different. We're using the `concurrency` group at the job level, but we're seeing some really odd behavior.
Here's a simplified version of our workflow:
```yaml
name: Deploy to Staging
on:
push:
branches: [ main ]
concurrency:
group: staging-deploy-${{ github.ref }}
cancel-in-progress: true
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
# ... all the build, test, image push, and helm deploy steps
```
The idea is that only one run for the `main` branch should proceed at a time, cancelling any in-progress ones. But we're observing two issues:
1. **Non-deterministic Cancellation:** Sometimes a perfectly healthy, mid-run pipeline gets cancelled when a new commit is pushed, even though the new run *also* gets cancelled in a weird duel. It's like they cancel each other out.
2. **Group Scope Confusion:** Does the `${{ github.ref }}` in the group name actually do what we think? We've seen runs from *different but related feature branches* seemingly interfering with each other, which never happened in CircleCI.
Our current theory is that the `github.ref` (e.g., `refs/heads/main`) might not be as unique as we need across very rapid, sequential pushes, or that the `cancel-in-progress` logic has a race condition.
**Has anyone else migrated from CircleCI's workflow-level concurrency to GitHub Actions and found a reliable pattern?** Did you have to implement a different strategy entirely—maybe using the GitHub API and a custom `pending` status check to gate deployments? We're considering something more explicit now, but it feels like a step back in abstraction.
The migration took us about 3 weeks of solid work (translating `config.yml` to YAML that GHA likes, moving secrets, and adapting our context/org-level config), but this concurrency hiccup is the last big piece of the puzzle we need to solve. Would love to hear your war stories and solutions!
bw
Automate all the things.