Bitbucket Cloud リポジトリをビルドする

Azure DevOps Services

Azure Pipelines では、すべてのプル要求を自動的にビルドして検証し、Bitbucket Cloud リポジトリにコミットできます。 この記事では、Bitbucket Cloud と Azure Pipelines の統合を構成する方法について説明します。

Bitbucket と Azure Pipelines は、よく統合された 2 つの独立したサービスです。 Bitbucket Cloud ユーザーが Azure Pipelines に自動的にアクセスすることはありません。 Azure Pipelines に明示的に追加する必要があります。

Bitbucket リポジトリへのアクセス

ビルド中にコードをフェッチするには、リポジトリへのアクセス権を Azure Pipelines に付与する必要があります。 さらに、パイプラインを設定するユーザーには Bitbucket への管理者アクセス権が必要です。これは、その ID を使用して Bitbucket に Webhook を登録するためです。

パイプラインの作成時に、Azure Pipelines に Bitbucket Cloud リポジトリへのアクセスを許可するための認証の種類は 2 つあります。

OAuth 認証

OAuth は、Bitbucket アカウントのリポジトリで使用を開始する最も簡単な認証の種類です。 Bitbucket 状態の更新は、個人の Bitbucket ID に代わって実行されます。 パイプラインが機能し続けるためには、リポジトリへのアクセスがアクティブなままである必要があります。

OAuth を使用するには、パイプラインの作成時にメッセージが表示されたら Bitbucket にログインします。 次に、OAuth 承認する をクリックします。 OAuth 接続は、後で使用するために Azure DevOps プロジェクトに保存され、作成されるパイプラインでも使用されます。

パスワード認証

ビルドと Bitbucket 状態の更新は、個人 ID に代わって実行されます。 ビルドが動作し続けるためには、リポジトリへのアクセスがアクティブなままである必要があります。

パスワード接続を作成するには、Azure DevOps プロジェクトの設定で サービス接続にアクセスします。 新しい Bitbucket サービス接続を作成し、Bitbucket Cloud リポジトリに接続するためのユーザー名とパスワードを指定します。

CI トリガー

継続的インテグレーション (CI) トリガーを使用すると、指定したブランチに更新をプッシュしたり、指定したタグをプッシュしたりするたびに、パイプラインが実行されます。

trigger:
- main
- releases/*

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

# A pipeline with no CI trigger
trigger: none

個々のコミットの CI のスキップ

また、プッシュが通常トリガーするパイプラインの実行をスキップするように Azure Pipelines に指示することもできます。 プッシュの一部であるコミットのメッセージまたは説明に [skip ci] を含めるだけで、Azure Pipelines はこのプッシュの実行 CI をスキップします。 次のバリエーションのいずれかを使用することもできます。

• [skip ci] または [ci skip]
• skip-checks: true または skip-checks:true
• [skip azurepipelines] または [azurepipelines skip]
• [skip azpipelines] または [azpipelines skip]
• [skip azp] または [azp skip]
• ***NO_CI***

条件でのトリガーの種類の使用

実行を開始したトリガーの種類に応じて、パイプライン内のさまざまなステップ、ジョブ、またはステージを実行するのが一般的なシナリオです。 これは、システム変数 Build.Reasonを使用して行うことができます。 たとえば、次の条件をステップ、ジョブ、またはステージに追加して、PR 検証から除外します。

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

新しいブランチがプッシュされたときのトリガーの動作

同じリポジトリに対して複数のパイプラインを構成するのが一般的です。 たとえば、アプリのドキュメントをビルドするパイプラインと、ソース コードをビルドするためのパイプラインがあります。 これらの各パイプラインで、適切な分岐フィルターとパス フィルターを使用して CI トリガーを構成できます。 たとえば、docs フォルダーに更新をプッシュするときに 1 つのパイプラインをトリガーし、もう 1 つのパイプラインをアプリケーション コードにプッシュするときにトリガーすることができます。 このような場合は、新しいブランチが作成されたときにパイプラインがどのようにトリガーされるかを理解する必要があります。

新しいブランチ (ブランチ フィルターと一致する) をリポジトリにプッシュするときの動作を次に示します。

• パイプラインにパス フィルターがある場合は、新しいブランチがそのパス フィルターに一致するファイルに変更を加えた場合にのみトリガーされます。
• パイプラインにパス フィルターがない場合は、新しいブランチに変更がない場合でもトリガーされます。

ワイルドカード

分岐、タグ、またはパスを指定する場合は、正確な名前またはワイルドカードを使用できます。 ワイルドカード パターンを使用すると、* は 0 個以上の文字と一致し、? は 1 文字に一致します。

• YAML パイプラインで * を使用してパターンを開始する場合は、"*-releases"のようにパターンを引用符で囲む必要があります。
• ブランチとタグの場合:
  • ワイルドカードは、パターン内の任意の場所に表示できます。
• パスの場合:
  • Azure DevOps Services を含む Azure DevOps Server 2022 以降では、パス パターン内の任意の場所にワイルドカードが表示される場合があり、* または ?を使用できます。
  • Azure DevOps Server 2020 以前では、最終的な文字として * を含めることができますが、ディレクトリ名を単独で指定する場合と何も変わりません。 パス フィルターの途中に 含め 、を使用しない場合があります。

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR トリガー

プル要求 (PR) トリガーは、指定されたターゲット ブランチのいずれかでプル要求が開かれるたびに、またはそのようなプル要求に対して更新が行われると、パイプラインを実行します。

pr:
- main
- releases/*

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

# no PR triggers
pr: none

情報提供の実行

情報実行では、Azure DevOps が YAML パイプラインのソース コードを取得できなかったことを示します。 ソース コードの取得は、プッシュされたコミットなどの外部イベントに応答して発生します。 また、内部トリガーに応答して発生します。たとえば、コードの変更があるかどうかを確認し、スケジュールされた実行を開始するかどうかなどです。 ソース コードの取得は複数の理由で失敗する可能性があります。多くの場合、Git リポジトリ プロバイダーによって調整が要求されます。 情報実行の存在は、必ずしも Azure DevOps がパイプラインを実行することを意味するとは限りません。

情報の実行は、次のスクリーンショットのようになります。

次の属性によって情報実行を認識できます。

• 状態が Canceled
• 期間は < 1s
• 実行名には、次のいずれかのテキストが含まれています。
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• 通常、実行名には、YAML パイプラインの読み込みが失敗する原因となった BitBucket/GitHub エラーが含まれています
• ステージ/ジョブ/ステップなし

情報実行の詳細について説明します。

制限事項

Azure Pipelines は、リポジトリから Azure Devops ポータルのドロップダウン リストに最大 2,000 個のブランチを読み込みます。たとえば、手動ビルドとスケジュールされたビルド 設定用の Default ブランチに読み込む場合や、パイプラインを手動で実行するときにブランチを選択する場合などです。 目的のブランチが一覧に表示されない場合は、目的のブランチ名を手動で入力します。

よくあるご質問

Bitbucket 統合に関連する問題は、次のカテゴリに分類されます。

• 失敗したトリガー: リポジトリに更新をプッシュするときにパイプラインがトリガーされません。
• 間違ったバージョン: パイプラインが実行されますが、ソース/YAML の予期しないバージョンが使用されています。

失敗したトリガー

CI/PR トリガーを使用して新しい YAML パイプラインを作成しましたが、パイプラインはトリガーされていません。

失敗したトリガーのトラブルシューティングを行うには、次の各手順に従います。

• YAML CI または PR トリガー UIのパイプライン設定によってオーバーライドされますか? パイプラインの編集中に、[...] 選択し、[トリガーを します。

  パイプライン設定 UI を

  リポジトリで使用可能なトリガーの種類 (継続的インテグレーション または pull request 検証) の設定、ここから YAML トリガーをオーバーライドする を確認します。

  

• Webhook は、Bitbucket から Azure Pipelines への更新を通信するために使用されます。 Bitbucket で、リポジトリの設定に移動し、次に Webhook に移動します。 Webhook が存在することを確認します。

• パイプラインが一時停止されているか無効になっているか。 パイプラインのエディターを開き、[設定] 選択して確認します。 パイプラインが一時停止または無効になっている場合、トリガーは機能しません。

• 正しいブランチの YAML ファイルを更新しましたか? ブランチに更新をプッシュすると、同じブランチ内の YAML ファイルによって CI 動作が制御されます。 ソース ブランチに更新をプッシュすると、ソース ブランチとターゲット ブランチのマージによって生じる YAML ファイルによって PR 動作が制御されます。 正しいブランチの YAML ファイルに必要な CI または PR 構成があることを確認します。

• トリガーを正しく構成しましたか? YAML トリガーを定義する場合は、ブランチ、タグ、パスに対して include 句と exclude 句の両方を指定できます。 include 句がコミットの詳細と一致し、exclude 句がそれらを除外していないことを確認します。 トリガーの構文を確認し、正確であることを確認します。

• トリガーまたはパスの定義に変数を使用しましたか? これはサポートされていません。

• YAML ファイルにテンプレートを使用しましたか? その場合は、トリガーがメインの YAML ファイルで定義されていることを確認します。 テンプレート ファイル内で定義されたトリガーはサポートされていません。

• 変更をプッシュしたブランチまたはパスを除外しましたか? 含まれているブランチに含まれるパスに変更をプッシュしてテストします。 トリガー内のパスでは大文字と小文字が区別されることに注意してください。 トリガーでパスを指定するときは、実際のフォルダーと同じケースを使用してください。

• 新しいブランチをプッシュしましたか? その場合、新しいブランチが新しい実行を開始しない可能性があります。 「新しいブランチが作成されたときのトリガーの動作」セクションを参照してください。

CI または PR トリガーが正常に動作しています。 しかし、彼らは今作業を停止しました。

まず、前の質問のトラブルシューティング手順を実行します。 次に、次の追加の手順に従います。

• PR でマージ競合が発生していますか? パイプラインをトリガーしなかった PR の場合は、パイプラインを開き、マージの競合があるかどうかを確認します。 マージの競合を解決します。

• プッシュ イベントまたは PR イベントの処理に遅延が発生していますか? これは通常、問題が 1 つのパイプラインに固有であるか、プロジェクト内のすべてのパイプラインまたはリポジトリに共通しているかどうかを確認することで確認できます。 いずれかのリポジトリへのプッシュまたは PR 更新でこの現象が発生した場合、更新イベントの処理に遅延が発生している可能性があります。 の状態ページでサービスの停止が発生しているかどうかを確認。 状態ページに問題が表示される場合は、チームが既に作業を開始している必要があります。 この問題に関する更新プログラムについては、このページを頻繁に確認してください。

ユーザーが YAML ファイルを更新するときに、トリガーのブランチの一覧をオーバーライドしないようにします。 これを行うにはどうすればよいですか?

コードを投稿するアクセス許可を持つユーザーは、YAML ファイルを更新し、追加のブランチを含める/除外することができます。 その結果、ユーザーは独自の機能またはユーザー ブランチを YAML ファイルに含め、その更新プログラムを機能またはユーザー ブランチにプッシュできます。 これにより、そのブランチに対するすべての更新に対してパイプラインがトリガーされる可能性があります。 この動作を回避する場合は、次のことができます。

1. Azure Pipelines UI でパイプラインを編集します。
2. トリガー メニューに移動します。
3. ここから YAML 継続的インテグレーション トリガーをオーバーライド 選択します。
4. トリガーに含める、または除外する分岐を指定します。

これらの手順を実行すると、YAML ファイルで指定された CI トリガーはすべて無視されます。

バージョンが正しくありません

パイプラインで間違ったバージョンの YAML ファイルが使用されています。 なぜでしょうか。

• CI トリガーの場合、プッシュしているブランチにある YAML ファイルが評価され、CI ビルドを実行する必要があるかどうかを確認します。
• PR トリガーの場合、PR のソースブランチとターゲットブランチをマージした結果の YAML ファイルが評価され、PR ビルドを実行する必要があるかどうかを確認します。