Bitbucket Cloud サービスのトラブルシューティング

robotsnoindex
robotsnoindex

非推奨

Bitbucket Cloud の webhook、接続統合フレームワーク、およびメール通知により、新しいサービス連携の作成は非推奨となりました。

Bitbucket Cloud サービスを構成してコミット データを Jenkins、(POST サービス経由で)自身のサービス、あるいはその他のサービスに送信する場合、さまざまな問題が発生する可能性があります。このページでは、問題の確認や検証に役立つ一般的なケースを取り上げます。ここに記載されていない問題が発生した場合や、このドキュメントへの改善リクエストがある場合、コメントでフィードバックをお寄せください。

データ受信をトリガーとするサービスについて

Bitbucket Cloud では、ご利用のアカウントやプロジェクト内のユーザーからデータを受け取ったときにサービスが実行されます。Git や Mercurial ではシステムが分散化されているため、ローカルでのデータ コミットは Bitbucket に影響を与えることはありません。サーバへの接続やコミット データのアップロードは、チェンジセットを Bitbucket にプッシュしたときに初めて行われます。  

サービス ブローカーは、Bitbucket がデータを正常に受け取ったあとにのみ、プッシュされたデータを受け取ります。プッシュには複数のチェンジセットが含まれる場合があるため、サービスも複数のチェンジセットを受け取る可能性があります。サービスの中には、チェンジセットの数を考慮するものがあります。たとえば、メール ブローカーは、チェンジセットの数に基づいて異なるメール メッセージを作成します。

サービスを手動でテストする方法

現在、サービスを手動でテストする機能の追加を進めていますが、サービスの手動テストはコマンド ラインから行うことができます。手動テストには、新しいファイルの作成またはファイルへの変更のコミットと、変更のサーバへのプッシュが含まれます。次の例では新しいファイルを作成しています。

Git リポジトリの場合、ローカル リポジトリから次の操作を行います。

  1. ディレクトリをリポジトリのルートに切り替えます。 

    $ cd mybb101-repo 
  2. servicetest.txt という名前の新しいファイルを作成します。

    $ cat /dev/null > servicetest.txt
    $ cat "this is a test" >> servicetest.txt
  3. ファイルをステージングに追加します。

    git add servicetest.txt
  4. 新しいファイルをコミットします。

    git commit -m "Testing the services"
  5. 変更を Bitbucket にプッシュします。

    git push
  6. コミットが Bitbucket の [コミット] タブに表示されることを確認します。
  7. サービスがコミット データを受け取っていることを確認します。

Mercurial リポジトリの場合、ローカル リポジトリから次の操作を行います。

  1. ディレクトリをリポジトリのルートに切り替えます。 

    $ cd myquotefork
  2. servicetest.txt という名前の新しいファイルを作成します。

    $ cat /dev/null > servicetest.txt
    $ cat "this is a test" >> servicetest.txt
  3. ファイルを Mercurial に追加します (add は新しいファイルの追加時にのみ必要で、更新のみの場合は不要です)。

    hg add servicetest.txt
  4. 新しいファイルをコミットします。

    hg commit -m "Testing the services"
  5. 変更を Bitbucket にプッシュします。

    hg push
  6. コミットが Bitbucket の [コミット] タブに表示されることを確認します。
  7. サービスがコミット データを受け取っていることを確認します。

手動テストが失敗する場合

コミットが対象のサービスに到達しない場合、次の点を確認します。

  • HTTP ステータス コードが 200 と 399 の間に含まれないリクエスト応答は却下されます。また、20 秒のタイムアウトが設定されています。ご利用のアプリケーションがこの時間内に応答できていることを確認します。
  • Jira DVCS Connector がファイアウォールの内側にある Jira Software バージョンで使用されているかどうかを確認します。この場合、POST サービスが対象の Jira Software インスタンスに到達できることを確認します。http://localhost:8080/ や http://office-pc/ などの URL は利用できません。
  • ログを確認します。HTTP トラフィックの許可やルーティングに関するほとんどすべての情報が記録されています。ログで、Bitbucket の IP アドレスからのトラフィックが到達しているかどうかを確認します。Bitbucket の現在の IP アドレスについては、「会社ファイアウォールを構成する際に、どの Bitbucket Cloud IP アドレスを使用する必要がありますか」をご参照ください。 
  • サーバとサービスに何も到達していない場合、POST サービスで http://posttestserver.com/post.php への送信を構成してテストを再び実行します。Bitbucket により、すべてのサービスが同時にトリガーされます。テスト サーバに POST が到達している場合、サービスにも到達していることが考えられます。サービスの構成を再確認します。
  • If all else fails, please check for reports of similar issues in the Atlassian Community or open a Support request.
最終更新日 2020 年 6 月 24 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.