2017-02-28 6 views
0

私たちはGitlab 8.16.5とGitlab API v3を使用しています。 Build &展開はGitlab-CIによって行われています。ビルドは、フィーチャーとホットフィックスのブランチを押すたびに作業を開始します。 Review、Staging & Productionの3つの環境があります。これで、レビューの展開ジョブについて2つの手動アクションが行われました。Review Accept & Review Reject。簡単に、環境のレビューは手動テスト用に設定されています。つまり、審査を受け入れることになり、手動テストは審査で拒否された&に合格し、手動テストは失敗しました。 ここでは、レビュー受け入れジョブでMRを作成する必要がありますが、ユーザーのプライベートトークンまたはプライベートアクセストークンを使用して同じものを作成することは望ましくありません。プライベートトークンを使用せずにGitlab CI経由でマージリクエストを作成

{401:Unauthorized access}と同じトリガートークンを試しましたが、 Doトリガは、ジョブの再構築のみを目的としていますか?

答えて

0

Gitlabの「標準的な」ワークフローは少し異なります。開発者がレビューに変更を提出するためにMRを作成するという考えがあります。そして、このマージのためにビルドが実行され、レビュアーはそれをテストし、テスト結果に応じてMRを受け入れるか拒否します。
このようにMRは常にユーザーによって行われます。

レビュー/テスト=>承認=> MR
を作成します。マージ後にもう一度テストする必要があるためです。

MRの作成>レビュー/テスト=>受け入れ(または拒否)

+0

ありがとうございました。マージ要求を受け入れることができないように手動アクションに基づいてパイプラインステータスを変更する方法はありますか。 –

+0

申し訳ありません私はあなたが意味するものを理解していません。パイプラインで手作業で作業することはできますが、MRはパイプラインには存在しません。したがって、明らかにしようとしたAPIを使用しているいくつかのハッキングを除いて、パイプラインからMRステータスを更新する標準的な方法はありません。 – CCH

関連する問題