Skip to content

Define customer-written GitLab automation scripts as outside scope of support

Greg Myers requested to merge docs-ansible-scope-of-support into master

PROBLEM

Custom scripts written to automate changes and updates on production GitLab instances can result in downtime and/or emergency and high-priority support tickets.

Why is this change being made?

Our official documentation is intended to act as the source of truth for how to install, update, configure, and manage self-managed GitLab instances in production.

We do not mention support for automation tools (Ansible, Chef, Puppet, SaltStack, etc) or custom script deployments of GitLab anywhere in our docs or handbook.

We have no official resources or documentation on how safely automate the steps in our documentation.

Customers sometimes create scripts to automate what we say to do in our docs. When instructions in our documentation gets updated, there is no way to notify customers that they need to update their script. If the custom scripts are not updated, it can cause problems and support tickets.

Support team should set clear expectations on what we are able to assist with in situations where a customer-written script or automation causes downtime or problems on a GitLab self-managed production instance.

Third-party automation tools and scripts are not currently part of Support Engineer onboarding or training.

In my experience, I find untested automation scripts often produce unexpected consequences.

Custom scripts can also lack safety checks that prevent an automation gone wrong from breaking all the things one at a time.

Does this MR meet the acceptance criteria?

Assign to DRI

  • Did you assign this change to the correct DRI of the page or information you are changing?

Conformity

Edited by Cynthia "Arty" Ng

Merge request reports