Issue Tracker の構成

Polyspace® Access インターフェイスからバグ トラッキング ツール (BTT) でチケットを作成できるようにするには、Issue Tracker を構成します。Polyspace Access では、Jira ソフトウェアおよび Redmine BTT との統合をサポートしています。BTT を Polyspace Access に統合しない場合は、[Provider] フィールドで [none] を選択します。

[Cluster Dashboard] で [Configure Apps] をクリックして [Cluster Settings] に移動します。設定を変更するたびに、[Save] をクリックして [Cluster Dashboard] に戻り、変更を反映させるために [Restart Apps] をクリックします。必ず、[Save] をクリックする前に [Validate on Save] を有効にしてください。

メモ

Windows® システムでは、指定するすべてのファイルのパスがローカル ドライブを指している必要があります。

前提条件

Jira ソフトウェア バグ トラッキング ツールの構成

Jira Server、Jira Cloud、および Jira Data Center で使用するように Issue Tracker を構成できます。[Issue Tracker] セクションで、以下の設定を指定します。

設定説明
Provider

[Jira] を選択します。

Jira deployment type

Jira インスタンスが Jira Server、Jira Cloud、Jira Data Center のいずれであるかを指定します。

Jira URL

組織の Jira インスタンスの URL を指定します。たとえば、https://jira.mycompany.com とします。

Jira インスタンスが HTTPS を使用して構成されている場合は、HTTPS を使用して構成された BTT インスタンスの追加を参照してください。

Authentication method

Issue Tracker で Polyspace Access ユーザーによる Jira ログインを認証するために使用する認証方法を指定します。たとえば、Jira Cloud の認証方法としては、OAuth 1.0a または OAuth 2.0 を選択できます。

OAuth 構成

認証方法として OAuth 1.0a または OAuth 2.0 を選択する場合は、まず、Jira 管理者が Jira でアプリケーション リンクを作成する必要があります。OAuth 1.0a は Jira Server、Jira Cloud、および Jira Data Center で使用できます。OAuth 2.0 は Jira Cloud と Jira Data Center で使用できます。

OAuth 2.0 アプリケーション リンクの場合、Jira 管理者はコールバック URL と権限を指定します。詳細は、こちらの OAuth 2.0 (3LO) アプリを参照してください。

OAuth 1.0a アプリケーション リンクの場合、Jira 管理者はアプリケーションの URL (Polyspace Access の URL) を指定し、RSA 公開鍵と秘密鍵のペアを生成します。詳細については、Atlassian OAuth ドキュメンテーションの手順 1 を参照してください。

OAuth 2.0 固有の構成

認証方法として OAuth 2.0 を選択する場合は、以下の追加の設定を指定します。

  
OAuth2 Client ID

"OAuth2 Client ID" は、OAuth 2.0 アプリケーション リンクの設定でのクライアント ID に一致している必要があります。

OAuth2 Client Secret

"OAuth2 Client Secret" は、OAuth 2.0 アプリケーション リンクの設定での secret 値に一致している必要があります。

OAuth2 Redirect URL

<hostname>/issuetracker/authn/oauth2/callback 形式でリンクを指定します。

ここで、<hostname> は Polyspace Access の URL です。たとえば、Polyspace Access の URL が https://access-machine.company.com:9443 の場合、OAuth2 Redirect URL を https://access-machine.company.com:9443/issuetracker/authn/oauth2/callback とします。

OAuth2 Scopes

アプリケーション リンクで有効にされている Jira API 権限をコンマ区切りリストとして指定します。

以下の権限が必要です。

  • read:jira-work

  • read:jira-user

  • write:jira-work

このフィールドを使用できるのは、Jira Cloud を展開タイプとして選択した場合のみです。

OAuth2 Site URL

組織の Jira Cloud インスタンスの URL を指定します。たとえば、https://mycompany.altassian.net とします。

このフィールドを使用できるのは、Jira Cloud を展開タイプとして選択した場合のみです。

OAuth 1.0a 固有の構成

認証方法として OAuth 1.0a を選択する場合は、以下の追加の設定を指定します。

設定説明
OAuth1 callback URL

[OAuth1 callback URL] の値は、Jira で指定されているアプリケーション URL と一致している必要があります (例: https://access-machine.company.com:9443)。

Jira configuration of oauth.

OAuth1 consumer key

Jira 管理者が Jira でアプリケーション リンクを構成するときに入力したユーザー キーの値を指定します。たとえば、OauthKey とします。

OAuth1 private key file

Jira 管理者が Jira でアプリケーション リンクを構成するときに生成した秘密鍵ファイルのパスを指定します。たとえば、/local/polyspace_access/jira_privatekey.pem とします。

メモ

Jira 秘密鍵を作成するときに指定するホストは、Polyspace Access URL で使用するホスト名と一致している必要があります。ホスト名が一致していない場合、たとえば Polyspace Access URL でホスト名の代わりに localhost を使用すると、Polyspace Access から Jira チケットを作成しようとするときにユーザー認証エラーが表示される可能性があります。

制限

  • カスタム フィールドが必須フィールドになっている場合、Polyspace Access では、これらのカスタム フィールドをもつ BTT チケットの作成をサポートしていません。ただし、フィールドが次のようになっている場合は例外です。

    • すべて数値。

    • 文字列のみの値。

    • 単一選択のカスタム フィールド。

  • ユーザーが Polyspace Access から Jira にログインして Jira チケットの作成を開始すると、そのセッションが有効期限切れになるまで、ユーザーは Jira セッションにログインされたままの状態になります。

  • Jira ソフトウェア version 8.4 以降では、ダーク機能を有効にしないでください。Jira でダーク機能を有効化する方法に関するページを参照してください。

Redmine バグ トラッキング ツールの構成

設定説明
Provider

Redmine

Redmine URL

組織の Redmine インスタンスの URL を指定します。たとえば、https://redmine.mycompany.com とします。

Redmine インスタンスが HTTPS を使用して構成されている場合は、HTTPS を使用して構成された BTT インスタンスの追加を参照してください。

このフィールドを使用できるのは、プロバイダーとして Redmine を選択した場合のみです。

Redmine API key

Redmine 管理者の API アクセス キーを指定します。

API キーを取得するには、管理者として Redmine のインスタンスにログインし、右上隅にある [My account] をクリックします。次に、右側のペインで [API access key] の下にある [Show] をクリックします。

Issue Tracker は API キーを検証しません。API が有効期限切れになっていたり、無効になっていたりしないか、定期的に確認してください。

このフィールドを使用できるのは、プロバイダーとして Redmine を選択した場合のみです。

制限

  • カスタム フィールドが必須フィールドになっている場合、Polyspace Access では、これらのカスタム フィールドをもつ BTT チケットの作成をサポートしていません。ただし、フィールドの値がすべて数値であるか、文字列のみの場合は例外です。

  • Polyspace Access から Redmine チケットを作成するには、Polyspace Access にログインするために使用するユーザー名が Redmine アカウントのユーザー名と一致している必要があります。

  • ユーザーが Polyspace Access から作成する Redmine チケットには、既定のフィールド値のみを入力できます。ユーザーが Polyspace Access で選択するチケットのフィールド値の一部は、Redmine チケットのフィールド値と一致しない場合があります。

HTTPS を使用して構成された BTT インスタンスの追加

BTT インスタンスが HTTPS を使用して構成されている場合、[Nodes] 設定の [CA File] フィールドに指定した証明書トラスト ストアに BTT の SSL 証明書を追加します。これらの設定を表示するには、[Cluster Dashboard] の [Configure Nodes] をクリックします。トラスト ストア ファイルによっては、BTT の SSL 証明書が既にトラスト ストアに含まれている場合があります。

通常、この証明書トラスト ストア ファイルは、Cluster Admin に HTTPS を構成するときに --ssl-ca-file で指定したファイルと一致します。Polyspace Access で HTTP と HTTPS のどちらの構成を使用するかを選択するを参照してください。

たとえば Linux® Debian® ディストリビューションで、BTT 証明書 btts_cert.pem をトラスト ストア ファイル trust_store.pem に追加するには、次のコマンドを使用します。

cat trust_store.pem btts_cert.pem > combined_cert.pem
このコマンドは、2 つのファイルの内容を連結して combined_cert.pem ファイルを出力します。自己署名証明書を使用して HTTPS を構成した場合は、自己署名証明書に BTT 証明書を追加してください。

構成を実行するには、[Nodes] 設定の [CA File] フィールドに combined_cert.pem のパスを入力し、変更を保存してからダッシュボードに戻り、アプリを再起動します。

Cluster Admin の構成に HTTPS を使用していない場合は、[CA File] フィールドに BTT の SSL 証明書のパスを指定します。

参考

トピック