Skip to main content

受信トレイ フィルター

GitHub 受信トレイ内の通知のフィルター処理について説明します。

次のサポートされているフィルターを使って、受信トレイ用のカスタム フィルターを作成できます。 カスタム フィルターの作成について詳しくは、「インボックスからの通知を管理する」をご覧ください。

カスタムフィルタの制限

カスタムフィルタは現在、以下をサポートしていません。

  • pull request や issue のタイトルの検索を含む、インボックスでの全文検索
  • is:issueis:pr、および is:pull-request クエリ フィルターの区別。 これらのクエリは、Issue と pull request の両方を検索結果として表示します。
  • 15 個以上のカスタムフィルタの作成
  • デフォルトのフィルタまたはその順序の変更
  • NOT または -QUALIFIER を使用した 除外 の検索

カスタムフィルタでサポートされているクエリ

使用できるフィルタの種類は次のとおりです。

  • リポジトリによるフィルター (repo: を使用)
  • ディスカッションの種類によるフィルター (is: を使用)
  • 通知理由によるフィルター (reason: を使用)
  • 通知作成者によるフィルター (author: を使用)
  • Organization によるフィルター (org: を使用)

サポートされている repo: クエリ

repo: フィルターを追加するには、リポジトリの所有者をクエリに含める必要があります: repo:owner/repository。 オーナーは、通知をトリガーする GitHub アセットを所有する Organization またはユーザです。 たとえば、repo:octo-org/octo-repo は、Organization 内の octo-repo リポジトリでトリガーされた通知を表示します。

サポートされている is: クエリ

GitHub での特定のアクティビティに関する通知をフィルター処理するには、is クエリを使用できます。 たとえば、リポジトリ招待の更新のみを表示するには is:repository-invitation を使用します。Dependabot alerts のみを表示するには、is:repository-vulnerability-alert を使用します。

  • is:check-suite
  • is:commit
  • is:gist
  • is:issue-or-pull-request
  • is:release
  • is:repository-invitation
  • is:repository-vulnerability-alert
  • is:repository-advisory
  • is:discussion

Dependabot alerts の通知からノイズを減らす方法については、「Dependabot アラートの通知を構成する」を参照してください。

is: クエリを使用して、通知がトリアージされた方法を記述することもできます。

  • is:saved
  • is:done
  • is:unread
  • is:read

サポートされている reason: クエリ

更新を受信した理由で通知をフィルター処理するには、reason: クエリを使用します。 たとえば、自分 (または自分が所属する Team) が Pull Request のレビューを要求されたときに通知を表示するには、reason:review-requested を使用します。 詳しくは、「通知について」をご覧ください。

クエリ説明
reason:assign割り当てられている Issue またはプルリクエストに更新があるとき。
reason:authorプルリクエストまたは Issue を開くと、更新または新しいコメントがあったとき。
reason:commentIssue または pull request にコメントしたとき。
reason:participatingIssue または pull request にコメントしたとき、または @mentioned が行われたとき。
reason:invitationTeam、Organization、またはリポジトリに招待されたとき。
reason:manualまだサブスクライブしていない Issue または Pull Request で [サブスクライブ] をクリックしたとき。
reason:mention直接 @mentioned されたとき。
reason:review-requested自分または自分が参加している Team が、プルリクエストのレビューをリクエストされたとき。
reason:security-alertリポジトリに対してセキュリティアラートが発行されたとき。
reason:state-changeプルリクエストまたは Issue の状態が変更されたとき。 たとえば、Issue がクローズされたり、プルリクエストがマージされた場合です。
reason:team-mentionメンバーになっている Team が @mentioned されたとき。
reason:ci-activityリポジトリに、新しいワークフロー実行ステータスなどの CI 更新があるとき。

サポートされている author: クエリ

ユーザーごとに通知をフィルター処理するには、author: クエリを使用します。 作成者は、通知を受け取るスレッド (例: issue、pull request、gist、ディスカッション) の元の作成者です。 たとえば、Octocat ユーザーによって作成されたスレッドの通知を表示するには、author:octocat を使用します。

サポートされている org: クエリ

Organization を指定して通知をフィルター処理するには、org クエリを使用できます。 クエリで指定する必要のある Organization は、GitHub で通知されているリポジトリの Organization です。 このクエリは、複数の Organization に属していて、特定の Organization の通知を表示する場合に便利です。

たとえば、octo-org の Organization からの通知を表示するには、org:octo-org を使用します。

Dependabotカスタムフィルタ

Dependabot を使って依存関係を最新の状態に保つには、次のカスタム フィルターを使用および保存できます。

  • is:repository_vulnerability_alert: Dependabot alertsの通知を表示します。
  • reason:security_alert: Dependabot alertsとセキュリティ更新プログラムの Pull Request の通知を表示します。
  • author:app/dependabot: Dependabot によって生成される通知を表示します。 これには、Dependabot alerts、セキュリティアップデートのプルリクエスト、およびバージョン更新のプルリクエストが含まれます。

Dependabot の詳細については、「Dependabot アラートについて」を参照してください。