How to disable a build rule for everyone, including sysAdmin
Is there a way to disable a build rule for everyone including system Admins? If so can clear instructions be provided for that?
The situation we have is that we have a build rule to a server set. It has history, and we're at a point that we absolutely do not want anyone to deploy to that server set until we are done with the tests being executed on the server.
We don't want anyone including systemAdmin to accidentally click the 'run' button that would cause us to build and deploy to that server set again.
There is a lot of anxiety from some team members over the fact that "it could happen," and they are contemplating deleting the build rule to ensure it does not. But then we loose the history too.
Please sign in to leave a comment.
Hi John,
I understand the concerns, but wouldn't it be easier to simply remove the permissions for that project from all the users? A system administrator might be able to re-take the permissions and run it manually, but at that point it will be a malicious action, comparable to re-enabling a disabled build.
Automatic triggers can be stopped, but manual builds can still be run normally. Another option would be to disable all the build steps in the build configuration, so that even if somebody accidentally triggers it nothing happens.
We have a related request here, please feel free to watch and vote: https://youtrack.jetbrains.com/issue/TW-23529
How would we remove the permission for that project from all users?
System Administrator isn't a group that we can change roll for. So they automatically and always have the ability to do the manual deployment.
We do not have triggers. These are ONLY activated by manual deployment. We're not worried about a sys-admin "retaking" permission or "reenabling" a build. It's making sure they don't accidentally run when they are scrolling through the list of deployables. It's an upper management concern. The button is there, it is activated, it could be pushed, and right now we cannot have that "could be pushed" risk....
We have disabled the build steps, but that is an incredibly tedious step as we go through all the build steps for all the apps on the server and disable them. I'm looking for simple, quick and easy. Disabling each build configuration is a workaround that we're using -- but it's not a great workaround.
TW-23529 looks good, but not quite the same since that appears to only be for triggered builds.
Thank you.
Hi John
The issue in the tracker is to remove the "Run" button, which is only used for manual runs. It's thought for builds that are only run automatically, but of course the feature would be implemented precisely to stop builds from being manually triggered on builds which aren't expected to be run manually. There is a couple issues to disable build configurations entirely, but this are already closed as the main goal of those is achieved by simply disabling the triggers, we haven't really had many situations where people requested stopping that altogether to prevent mistakes.
Removing the permissions for that project should be good for most users, although system administrators would still have server-wide capabilities, so you are right, this would be complicated. The idea I was thinking of was that this kind of configuration is probably on its own project and the permissions for most users can be removed for that project, and was thinking more of a project administrator than system administrator.
I'll try to suggest some workarounds for the meantime, taking into account that malicious action is not expected:
-Create an agent requirement that no agent will be able to match (say, agent name equals <random string>). This will allow triggering the build but it won't run because no agents are able to run it.
-Create a script that uses the REST API to iterate through the configuration steps and automatically disables them. If you expect this situation to happen regularly, this might be an option to reduce the overhead on doing it. You can also set the agent requirements through the script, so this might be flexible.
Hope this helps.