Approval step on gitlab CI

Question

I want to discuss and to know more approaches about how to add a approval step on Gitlab CI Everybody knows that gitlab doesn't has a approval feature on the pipeline

I did a small template to add a kind of approval step in any step

this is the content of the template

.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

how does it work?

This template checks if the user who triggered the job is inside the USERS variable (array) The check happens on before_script block and it works in any step (without overwrite the before_script)

It works very well but I want to know if there is a better approach to do it.

Answer 1

Anyone with write access to the repository can change that file and add themselves to the list. But my concern with the scripted approach is a different one, as you may end up confusing your future self or your successor(s) with a block of code to maintain. The person who triggers a job may be a different person than the one who would review the code, also I'm not sure if you want to assume that triggering equals approval.

Let me explain what I've been doing: Imagine having a development and a master branch - only master gets deployed automatically. Nobody can push directly to master when you protect the branch. Everything has to be merged into masterby using merge requests. Permission-wise it still comes down to having write access (developer or a higher role). This keeps the step of approval in the GUI (where you would expect an approval feature to appear once it's added). Additionally, accepting a merge request will trigger a dedicated e-mail notification.

This works very well when you make sure merging into master is a taboo except for the lead developers. Maybe this is not applicable for your situation but a different approach; and even this one needed my successor to be educated on where to click in order to approve a merge request.

If you want to fast-track the deployment of some developers you can assign them a higher role and use my suggested approach to let them push to the master branch directly. That way they skip the step of awaiting approval.