Avoid merging or pushing to the master/main branch on Fridays

How to Use GitLab System Administration
1

Hi everyone!

I am running a self-managed instance of GitLab Community Edition (version 15.10.7). At our company, we have a policy that no deployments should be done on Fridays. The term “deployment” here means merging or pushing to the master/main branch. However, this policy is only a spoken one, so there is no guarantee that it will be followed. Because of that, sometimes people still deploy on Fridays, and sometimes, for whatever reason, we need to rollback our code.

I would love to know if there is any way to avoid merging/pushing to the master/main branch only on Fridays. It would be something like the “maintenance mode,” but restricting it only to the master and main branches. The other branches should still behave without any restrictions.

Ideally, it would be really nice to see a message like “Our company policy says that no deployments should be done on Fridays. Please do it next Monday!” What are your thoughts on that? Maybe a script using the GitLab API could do this trick?

Thanks a lot for any direction on this matter.

2

You could use a script with the REST API to modify the protected branches setting and who is allowed to merge/push. The error message needs documentation though, as it could lead to folks suspecting an error with GitLab itself.

Example code with python-gitlab is described in this blog post: Efficient DevSecOps workflows: Hands-on python-gitlab API automation | GitLab where no access = 0.

Recommend testing this script in a test project first, and get team buy-in whether it is not too disruptive to their workflows.

An alternative, more soft approach is to modify the pipeline with a before_script in the default branch which triggers the deployment. This script can check for the current day (note: needs to be timezone aware if you are working with global teams) and then exit 1 the pipeline with a telling error message.

Problem is that folks might override the script to force a deployment. Though, this audit log is persisted in Git history. And then it is a matter of team trust, transparency and responsibilities. I.e. raising awareness for production incidents that cause extra work for others on the team.

2 Likes