[Feature]: Temporarily Lock/Disable Environment

[bensofficial]

Contact Details

No response

Describe the feature

It would be useful for me to have locks without a time limit (even without deployment) when performing maintenance on a test server, for example. This would basically be a feature to temporarily lock an environment.
A prerequisite is that the test server admins can also unlock environments (e.g. if a user forgot to remove it, or forcibly unlock it when a maintenance starts to disable the test server).

[egekocabas]

Thanks @bensofficial for submitting the first feature request for Helios 🚀

• We planned to change the locking mechanism to give more control to the repository admins, the related issue can be found here [Feature]: Adjust who can lock/unlock environments and auto-release environments #320.
• We should also consider adding the lock button without any deployments so thank you for that, we might add this in this sprint and let you know when decided 👍🏻
• Currently we retrieve permissions directly from GitHub. Do all test server admins have Maintain or Admin role for the repository? If not, we could consider making this permission configurable within Helios' repository settings.

[bensofficial]

@egekocabas Thank you for your reply.
No, I have neither maintain nor admin rights. I don't have a clear opinion on how to handle this particular case. Maybe you can discuss this in one of your next meetings, whether it is best to give me additional rights in the GitHub repository or add a special permission check (this would then probably be a feature specifically for Artemis with no/very little use in other projects).

[egekocabas]

Hey @bensofficial

If you can provide the GitHub profiles of other test server admins, we can temporarily add them (hardcoded) as allowed users. This will enable them to unlock any environment and manage its enable/disable status.

Currently, our Helios team members' GitHub tags are hardcoded for access control as well, since we are not admins or maintainers of any repository. However, we should be able to grant these accesses within Helios, as we retrieve permissions directly from GitHub. In the next sprints, we plan to refine this with a more granular access management approach.

Let us know if you'd like us to proceed with this way. Tags can be included with this issue 👍