Because we work with so many npm packages, and because we sometimes have multiple developers working on the same package at the same time, we constantly are using the ?d=[version] at the end of URLs to test specific bundles. For instance, I might be testing my npm package version 1.1.0 in ?d=123 while my colleague might be testing our npm package version 1.1.1 in ?d=124.
In order to use these URL params, the deployment bundle needs to be on deck. The second someone terminates that bundle, the URL params no longer work. The other developers on our various teams may not be aware that a specific bundle is still being used to test with.
We would like to request a way to lock a bundle on deck if a developer needs it to stay on deck while testing over a period of days. Maybe the lock is only removable by the developer who placed the lock or by someone with admin status.
Guest
Glad to hear we're on the same page. We'll consider this idea and plan on our roadmap. Can't promise a date yet, but we'll put this into future consideration and wait for the right opportunity.
Hi Fatih,
Thanks for getting back to me on this one, and yes, this is definitely along the lines of my thinking.
This, ^^ , specifically, sounds right on track. I especially like the note part where you can add a note on why it is locked. That would be very helpful in case the person who locked it forgets to unlock when they are done. We can easily see who and why it was locked. Great idea!
Hi,
Thanks for submitting this idea. It makes a lot of sense. I want to understand your use case a little bit more. Are you looking for a simple lock and knock sort of capability that we currently have in composer where when userA opens a story, they get the story automatically locked and if any other user opens the story, they see read-only version with the note that says this story is currently being edited by userA, want to knock (that shows a notification on other user's screen), and takeover button that force takes over the lock to the userB. Imagining similar type of capability, but probably not that real-time interaction needed. So perhaps, just manual lock/unlock buttons for any user has Arc "developer" permission. And if a deployment is locked, you can force "take over" the lock onto yourself, then unlock, terminate or do other actions. Possibly we can also include a generic "note" or a "lock note" field to allow you add some notes on why the deployment is locked.
Is this aligned with what you were thinking?