☰

Bitbucket から Gitlab Webhook へのパイプラインをトリガーする

tag-icon • tag-icon gitlab bitbucket gitlab-runner
Bitbucket から Gitlab Webhook へのパイプラインをトリガーする

フォローしていますオンプレミスシナリオ: 開発者は Bitbucket でアプリに取り組んでおり、運用担当者は Gitlab で「Gitops」関連の作業を行っています。Gitlab パイプラインを介してビルドとデプロイメントを自動化し、実装する方法を探しています。ビルド部分はすでに機能しています。ただし、ブランチを区別する必要があります。すべてのブランチをデプロイする必要はありません。特に本番環境は手動でデプロイされます。

Webhook には、デプロイメント ステージで設定しようとしたブランチが含まれているため、

only:
  - dev

同様に

  rules:
    - if: '$TOKEN_BRANCH != $PROD_BRANCH'

ただし、どちらの方法でも、デプロイメント パイプラインは引き続きトリガーされます。

2 つの回避策が思い浮かびました。

1 つの選択肢は、「コミット後のフック」を介して Bitbucket リポジトリをミラーリングすることですが、一方ではこのプラグインにはコストがかかり、他方ではミラーリング用の 2 番目のプラグインが必要になります。そして、私が見つけた唯一のプラグインは、もはやメンテナンスされていません。

2 番目のオプションは、Bitbucket Webhook 経由でもトリガーできる「プル ミラーリング」を使用できるように Gitlab Ultimate のライセンスを取得することです。

リポジトリのミラーリングは使用せず、唯一の使用例は、デプロイメント用にブランチを変更する上記のすべての方法が機能する「ローカル リポジトリ」で Gitlab パイプラインを使用できるようにすることです。そのため、すでに利用可能なリソースを使用する方法を見つけたいと思います。

これについてのあなたの考えを聞けて嬉しいです!

編集： パイプラインの各部分:

variables:
  PROD_BRANCH: main

before_script:
  - TOKEN_BRANCH=$(cat $TRIGGER_PAYLOAD | jq -r '.changes[0].ref.displayId')

deploy:
  stage: deploy
  tags:
    - openshift
  rules:
    - if: $TOKEN_BRANCH != $PROD_BRANCH
  • echo $TOKEN_BRANCH は "main" を返します。
  • ルール内: パイプラインのこの部分は、次のステートメントが true の場合にのみトリガーされます。
  • 「main == main」であり、「!=」ではないため、パイプラインの「deploy」ステージは実行されるべきではありません。しかし、実行されます...

いくつかのバリエーション

rules:
  - if: '$TOKEN_BRANCH !~ $PROD_BRANCH'

rules:
  - if: '$TOKEN_BRANCH =~ $PROD_BRANCH'
    when: never

これらのケースでは逆のことが起こります。パイプラインにはデプロイ ステージがなく、Gitlab の「パイプライン」ビューにもステージが表示されません。

答え1

有効な解決策が見つかりました:

「ルール」が機能しなくなったため、デプロイメント ステージのスクリプト部分で「if ループ」を使用するようになりました。そのため、デプロイメント ステージは毎回トリガーされますが、ロジック (= デプロイメント) はトークンにそれぞれのステージが含まれている場合にのみ実行されます。

deploy-to-test:
  stage: deploy
  variables:
    PROD: master
  tags:
    - openshift
  script:
    - >
      if [ "$TOKEN_BRANCH" != "$PROD" ]; then
      ---logic---
      else
        echo "skipping ..."
      fi

関連情報