feat: add disable_lock input to bypass deployment locking#453
Open
mohammad19991 wants to merge 4 commits intogithub:mainfrom
Open
feat: add disable_lock input to bypass deployment locking#453mohammad19991 wants to merge 4 commits intogithub:mainfrom
mohammad19991 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
Contributor
|
👋 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 |
Author
I appreciate your feedback @GrantBirki. |
Contributor
|
We tag in @nobe4 as our review buddy to run CI and make sure it's all green! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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