feat: add disable_lock input to bypass deployment locking#453
feat: add disable_lock input to bypass deployment locking#453mohammad19991 wants to merge 4 commits intogithub:mainfrom
Conversation
Adds a new boolean input `disable_lock` that completely skips all locking logic when set to true. Useful for workflows where concurrent deployments are safe (e.g. iOS/Android uploads to TestFlight/Play Store) since each artifact upload is additive and independent. When enabled: - .lock and .unlock commands return an informational message instead of modifying lock state - Lock acquisition is skipped during deploy - Lock check and release are skipped in post-deploy
- Add tests for disable_lock in main.test.js: - deploy with disable_lock skips lock acquisition - .lock command returns informational comment and safe-exit - .unlock command returns informational comment and safe-exit - Add test for disable_lock in post-deploy.test.js: - skips lock check and release when disable_lock is true - Rebuild dist via npm run all (format + lint + package)
- Add disable_lock row to the inputs table in README.md - Add "Disabling Locks" section to docs/locks.md explaining the use case (e.g. iOS/Android uploads to TestFlight/Play Store) and the behavior when the option is enabled
|
👋 Hey @mohammad19991 this looks great! I can see the use case for this and think a non-breaking new input flag is the right way to do this. You will need to update this file |
I appreciate your feedback @GrantBirki. |
|
We tag in @nobe4 as our review buddy to run CI and make sure it's all green! |
|
@GrantBirki following up to see if we have any updates regarding the PR. |
|
@mohammad19991 I don't work at GitHub any more so I cannot merge this PR. The current maintainers will need to do so. |
2 participants
Problem
For workflows like iOS/Android builds that upload to TestFlight or the Play Store, deployment locking is irrelevant — each artifact upload is additive and independent, so concurrent deployments can never conflict.
Currently, the action always acquires a lock before deploying, adding unnecessary friction (and potential failures) in these scenarios.
Solution
Add a new boolean input
disable_lock(default:false) that completely bypasses all locking logic when set totrue.When enabled:
.lockand.unlockcommands reply with an informational comment instead of modifying lock stateNormal locking behavior is fully preserved when
disable_lockisfalse(the default), so this is a non-breaking change.Example usage