Fix deprecation logic which could auto-enable services
What does this MR do?
Due to the way Gitlab::ConfigMash works, when auto-vivifaction is enabled, []
method will create an empty Hash if the specified key is not present. This means in scenarios where unicorn['enable'] is not at all set in gitlab.rb, when we try to fetch unicorn['enable'] to check for deprecations, because the key enable
is not present, it will cause unicorn['enable'] to be an empty Hash. Because we check for nil
-ness of service['enable'] to include enable/disable recipes and because an empty hash is not nil
, we will end up enabling the unicorn service, and boom!
We should return early if the setting is not at all present.
Related issues
Closes #6126 (closed)
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion
Required
-
Merge Request Title, and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com -
Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks -
trigger-package
has a green pipeline running against latest commit
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Documentation created/updated -
Tests added -
Integration tests added to GitLab QA -
Equivalent MR/issue for the GitLab Chart opened