Support For Granular Locking Mechanisms.
- Dominant language
- TypeScript
- Stars
- 576
- Forks
- 74
- Avg merge
- 11h 7m
- Merged PRs (30d)
- 1
Description
### Details
First of all, we really thank you for this project. It's really one of my favorite GHA related projects.
## The Problem
We recently realized that sticky locks lock on a user level, not on a PR level.
This recently caused a problem for us because one of our developers forgot to merge and deployed another PR, effectively rolling back the changes of his previous PR.
## The Suggestion
We would like it if locks could also work on a PR or Branch basis.
---
I would be glad to contribute if that's ok, but I wanted to check if my assumption and suggestion was valid first.
Contributor guide
Research direction
No files, tests, or entry points are named. Start by locating the existing sticky-lock handling and deployment workflow, then clarify whether locks should be scoped to pull requests, branches, or both. Done should include the agreed granular behavior and coverage for the relevant locking cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, typescript
- Domain
- ci-cd, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100