我们将自托管的 gitlab-ce 升级到最新的 11.11，它引入了多个审阅者合并请求批准功能。尽管这需要通过gitlab-rails console.
在运行我们的 gitlab 实例的机器上，我跑到gitlab-rails console一个 ruby 控制台，我在其中Feature.enable(:approval_rules)输入并按 Enter，但我得到：
>> Feature.enable(:approval_rules)
Nothing known about Feature.enable(
我对红宝石没有太多经验，所以不确定哪里做错了。我在网上进行了搜索，但我找到了有关如何使用 Ruby 的“功能标志”进行开发的文档，但没有找到如何将它们作为应用程序的最终用户启用。
你可以通过 GitLab api 来完成。
https://gitlab.myhost.com/api/v4/features/approval_rules使用有效负载POST
{
"value": true
}
https://docs.gitlab.com/ee/api/features.html
此外，我发现从 11.9 升级到 11.10 时会自动启用新的审批规则工作流，尽管我的经验可能有所不同。如果您对该 API 端点执行 GET，您将能够看到其当前状态。
如果它已经启用，您可能会将新的批准规则实施与 EE 功能Multiple Approval Rules 混淆。我只提到-ce你问题中的标签。
使用GitLab 13.5（2020 年 10 月），实际功能标志适用于所有人：
功能标志在所有层级都可用
- 在 GitLab 11.4 中，我们引入了功能标志。
- 在 GitLab 12.2 中，我们引入了百分比推出和用户 ID功能标志策略。
- 在 GitLab 13.1 中，我们引入了 Feature Flag用户列表，并支持每个环境的多个 Feature Flag 策略。
今年早些时候，我们承诺将 18 个功能转移到我们的开源核心产品中，并通过在最后一个版本的 Starter 中提供功能标志，迈出了兑现这一承诺的第一步。
现在，我们已正式完成将功能标志移至我们的核心产品。我们很高兴将这些功能提供给更多的 GitLab 社区，并看到它将对您的开发工作流程产生的积极影响。
这包括，仍然使用GitLab 13.5（2020 年 10 月）：
Feature Flags 灵活的部署策略
当您
percent rollout今天使用该策略时，粘性或体验一致性仅由用户 ID 决定。这可能是限制性的；例如，匿名用户不会受到此策略的影响。我们通过使您能够根据会话 ID、用户 ID 或随机（无粘性）定义粘性来改进此推出策略。这使您可以更好地控制推出，并允许您支持匿名用户的粘性。
功能标志 API更多的是关于创建/更新/删除。
您必须使用功能标志策略才能启用/禁用功能标志。
Feature.disable(:feature_flags_new_version)
Feature.enable(:feature_flags_new_version)
另请参阅GitLab 13.6（2020 年 11 月）
在功能标志更改时触发 Webhook
作为开发人员，您可以将 GitLab 的 webhook 功能用于各种事件，例如 MR 事件、管道事件、作业事件和部署事件。在此版本中，您现在可以在打开或关闭功能标志时使用 webhook 事件。此添加简化了更新 CI/CD 管道、接收 Slack 事件通知等的过程。非常感谢Sashi为社区做出的巨大贡献！