Support For Granular Locking Mechanisms.

[flaxinger]

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.

[GrantBirki]

👋 Hey @flaxinger! I'm really glad you enjoy using this project. I am the core maintainer of this project (and still am) even though I am no longer a staff member at GitHub. I still hope to contribute to this project though and happy to answer some questions!

We recently realized that sticky locks lock on a user level, not on a PR level.

This is actually 100% intended. It might not be the best implementation for every team, but this project is heavily inspired by the deployment standards at GitHub. GitHub uses @hubot to deploy changes internally (as seen all over in GitHub's blog posts) and so this project mirrors a lot of the functionality of Hubot in that same nature.

The logic boils down to this: "The deployment lock for a given environment is bound to a single user, not a PR. That user is ultimately responsible for that environment while they have the lock and deploy any PR/branch until they release it".

The idea behind this is that something could go wrong when deploying a PR branch, and that user might need to revert by deploying main or perhaps even a different feature branch.

This logic is quite core to the operating principals at GitHub and also the inspiration behind this project.

---

Let me know if that helps answer your questions! 🙇