gitlab CI的审批步骤

Question

我想讨论并了解更多关于如何在Gitlab CI上添加审批步骤的方法每个人都知道gitlab在管道中没有审批功能

我做了一个小模板，在任何步骤中添加一种审批步骤

这是模板的内容

.approval_template:
  image: node:buster
  before_script:
    - |
      cat <<'EOF' >> approval.js
      var users = process.env.USERS.split(',');

      if (users.includes(process.env.GITLAB_USER_LOGIN)) {
          console.log(process.env.GITLAB_USER_LOGIN + " allowed to run this job")
          process.exit(0)
      } else {
        console.log(process.env.GITLAB_USER_LOGIN + " cannot trigger this job")
        console.log("List of users allowed to run this job")
        for (user in users)
        {
          console.log(users[user])
        }
        process.exit(1)
      }
      EOF
    - node approval.js
    - rm approval.js
  when: manual

它怎麽工作?

该模板检查触发作业的用户是否在USERS变量(数组)中。检查发生在before_script块上，并且可以在任何步骤中工作(不会覆盖before_script)

它工作得很好，但我想知道是否有更好的方法来做。

Answer 1

对存储库具有写访问权限的任何人都可以更改该文件，并将自己添加到列表中。但我对脚本化方法的担忧是不同的，因为您可能最终会将您未来的自己或您的继任者与要维护的代码块混淆。触发作业的人可能与审核代码的人不同，而且我不确定您是否想假设触发等于批准。

让我来解释一下我一直在做什么:想象一下有一个development和一个master分支--只有master会自动部署。当你使用protect the branch时，没有人可以直接推送到master。必须使用merge请求将所有内容合并到master中。在权限方面，它仍然需要拥有写访问权限(开发人员或更高的角色)。这保留了GUI中的审批步骤(在添加审批特性后，您会期望在该步骤中出现审批特性)。此外，接受合并请求将触发专用电子邮件通知。

当您确保合并到master是一个禁忌时，这是非常有效的，除了主要的开发人员。也许这不适用于您的情况，但这是一种不同的方法；即使是这一种方法，也需要我的继任者接受在哪里单击才能批准合并请求的培训。

如果您想快速跟踪一些开发人员的部署，您可以为他们分配一个更高的角色，并使用我建议的方法让他们直接推送到master分支。这样，他们就可以跳过等待批准的步骤。