Шаг утверждения на gitlab CI - PullRequest
Новая
       73

Шаг утверждения на gitlab CI

0 голосов
/ 29 мая 2020

Я хочу обсудить и узнать больше подходов о том, как добавить шаг утверждения в 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)

Он работает очень хорошо, но я хочу знать, есть ли лучший подход для этого .

1 Ответ

1 голос
/ 31 мая 2020

Любой, у кого есть доступ на запись в репозиторий, может изменить этот файл и добавить себя в список. Но меня беспокоит другой подход, основанный на сценариях, так как вы можете в конечном итоге запутать себя или своих преемников блоком кода, который необходимо поддерживать. Человек, инициирующий задание, может быть другим человеком, чем тот, кто будет просматривать код, также я не уверен, что вы хотите предположить, что запуск равняется одобрению.

Позвольте мне объяснить, чем я был выполнение: Представьте, что у вас есть ветки development и master - только master развертывается автоматически. Никто не может отправить sh напрямую на master, когда вы защищаете ветку . Все должно быть объединено в master с помощью запросов на слияние. С точки зрения разрешений все сводится к наличию доступа на запись (разработчик или более высокая роль). Это сохраняет шаг утверждения в GUI (где вы ожидаете, что функция утверждения появится после ее добавления). Кроме того, принятие запроса на слияние вызовет специальное уведомление по электронной почте.

Это работает очень хорошо, если вы убедитесь, что слияние с master является табу, за исключением ведущих разработчиков. Возможно, это не применимо к вашей ситуации, но другой подход; и даже этому требовалось, чтобы мой преемник знал, где щелкнуть, чтобы утвердить запрос на слияние.

Если вы хотите ускорить развертывание некоторых разработчиков, вы можете назначить им более высокую роль и использовать мою предложенный подход, чтобы позволить им pu sh к ветке master напрямую. Таким образом они пропускают этап ожидания одобрения.

...