slack
1.0.0
Slack 用の GitHub 統合により、あなたとあなたのチームは Slack チャネル内で GitHub プロジェクトを完全に把握できるようになり、アイデアを生成し、問題を優先順位付けし、他のチームと協力してプロジェクトを進めることができます。この統合はオープンソース プロジェクトであり、GitHub によって構築および維持されます。
このアプリは、GitHub.com (クラウド ホスト型の GitHub Enterprise サービスを含む) と Slack.com を正式にサポートしています。
GHES と Slack.com の統合は、GHES 3.8 で GA になりました。 Slack と GHES を統合するための詳細な手順は、ここでご覧いただけます。
Slack 用の GitHub 統合をインストールします。 Slack ワークスペースにサインインすると、アプリにアクセス権を付与するように求められます。
アプリのインストール後、 /invite @githubを使用して関連チャネルに GitHub 統合を追加すると、GitHub の問題、プルリクエスト、およびリッチ テキストとしてレンダリングされたコードへのリンクのプレビューがワークスペースに表示されます。
アプリをインストールすると、GitHub アプリを個人アプリとして操作したり、チャネルからアクセスしたりできるようになります。アプリがワークスペースにインストールされると、GitHub アプリはすべてのパブリック チャネルで有効になります。プライベート チャネルの場合は、明示的に/invite @github招待する必要があります
この時点で、Slack と GitHub のユーザー アカウントがリンクされました。 GitHub に接続するように求められます。これは、アプリにアクセスするために必要な主な手順です。あるいは、 /github signin実行して接続することもできます。
接続すると、次のステップと利用可能な機能のリストが表示されます。
/githubスラッシュ コマンドは、組織またはリポジトリのアクティビティ/github subscribe <organization>/<repository>をサブスクライブするために使用できるsubscribe引数も受け入れます。
もともとアプリに「すべてのリポジトリ」へのアクセス権を与えており、Slack 用の GitHub 統合をインストールした後に GitHub 上に新しいプライベート リポジトリを作成した場合、 /github subscribeコマンドは新しいリポジトリで自動的に機能します。アプリをリポジトリのサブセットにインストールした場合、アプリは新しいリポジトリにインストールするように求めるプロンプトを表示します。
/githubスラッシュ コマンドは、 unsubscribeもサポートしています。リポジトリからの通知のサブスクライブを解除するには、 /github unsubscribe <organization>/<repository>を使用します。
アプリにアクセスを許可すると、GitHub アカウントと Slack アカウントに次の承認が与えられます。
| 許可範囲 | なぜそれが必要なのか |
|---|---|
| あなたとアプリの間のプライベートな会話にアクセスする | 指示をメッセージで伝えるため。 |
| メッセージ内の GitHub.com へのリンクを表示する | github.comからのリッチリンクをレンダリングするには |
| GitHub.com へのリンク プレビューをメッセージに追加する | github.comへのリッチ リンクをレンダリングするには |
| スラッシュコマンドを追加する | /githubスラッシュ コマンドを Slack ワークスペースに追加するには |
| ワークスペースまたは組織の名前、電子メール ドメイン、およびアイコンを表示します | 設定したサブスクリプションを保存するには |
| アプリとしてメッセージを投稿する | GitHub 上で発生したアクティビティを Slack で通知するには |
| 許可範囲 | なぜそれが必要なのか |
|---|---|
| コードへの読み取りアクセス | Slack でコード スニペットをレンダリングするには |
| アクション、コミットステータス、チェック、ディスカッション、問題、メタデータ、プルリクエスト、リポジトリプロジェクトへの読み取りアクセス | Slack で共有されたリンクのプレビューをレンダリングするには |
| アクション、問題、デプロイメント、プル リクエストへの書き込みアクセス | /githubコマンドを使用して Slack からアクションを実行するか、メッセージから直接アクションを実行するには |
リポジトリでは、アプリは、プル リクエストに関するopen 、 close 、およびre-openイベントと、サブスクライブしているリポジトリの問題を通知します。また、リポジトリのデフォルト ブランチへの直接pushも通知します。
Slack チャネルに関連するアクティビティを購読し、プロジェクトにとってあまり役に立たないアクティビティの購読を解除することで、通知をカスタマイズできます。
設定は/githubスラッシュ コマンドで構成します。
/github subscribe owner/repo [feature]
/github unsubscribe owner/repo [feature]
これらはデフォルトで有効になっており、 /github unsubscribe owner/repo [feature]コマンドで無効にできます。
issues - オープンまたはクローズされた問題pulls - 新規またはマージされたプル リクエスト、および「レビュー準備完了」とマークされたドラフト プル リクエストcommits - デフォルトのブランチ (通常はmain ) 上の新しいコミットreleases - 公開されたリリースdeployments - 展開ステータスの更新。これらはデフォルトでは無効になっていますが、 /github subscribe owner/repo [feature]コマンドで有効にできます。
workflows - アクションワークフロー実行通知reviews - プルリクエストのレビューcomments - 問題とプルリクエストに関する新しいコメントbranches - 作成または削除されたブランチcommits:* - 任意のブランチにプッシュされたすべてのコミット+label:"your label" - ラベルに基づいて問題、プルリクエスト、コメントをフィルターします。discussions - 作成されたディスカッションまたは回答されたディスカッション複数の設定を一度に登録または登録解除できます。たとえば、プル リクエストのレビューとコメントのアクティビティを有効にするには、次のようにします。
/github subscribe owner/repo reviews comments
そして、それをオフに戻すには:
/github unsubscribe owner/repo reviews comments
ブランチ フィルターを使用すると、コミット通知をフィルター処理できます。デフォルトでは、コミット機能をサブスクライブすると、デフォルトのブランチ (つまりメイン) の通知が届きます。ただし、特定のブランチ、ブランチのパターン、またはすべてのブランチでフィルタリングすることを選択できます。
/github subscribe org/repo commitsデフォルトのブランチからのコミット通知を取得します。/github subscribe org/repo commits:*すべてのブランチにわたるコミット通知用。/github subscribe org/repo commits:myBranch 。/github subscribe org/repo commits:users/*使用します。`@github unsubscribe org/repo commits を使用してコミット機能を購読解除できます。
注: 以前は、すべてのブランチを表すためにcommits:all使用していた可能性があります。 「all」は予約されたキーワードではなくなりました。今後は、すべてのブランチを表すために「*」を使用する必要があります。すでに「commits:all」を使用して構成している場合でも、心配する必要はありません。コミット構成を更新するまでは引き続き機能します。
ラベル フィルターを使用すると、必要なラベルの許可リストに基づいて受信イベントをフィルター処理できます。
これは、required-label フィルターの影響を受けるイベント タイプの概要です。
| イベント | フィルタリングされています |
|---|---|
| 引く | ✅ はい |
| コメント（PRと問題） | ✅ はい |
| 問題 | ✅ はい |
| レビュー | ✅ はい |
| コミット/プッシュ | いいえ |
| 支店 | いいえ |
以下を使用してフィルターを作成します。
/github subscribe owner/repo +label:"priority:HIGH"
これにより、値priority:HIGHを持つ必須ラベル フィルターが作成されます。フィルターをサポートする受信イベントは、そのラベルが付けられていない限り破棄されます。
既存のフィルタを更新するには、新しいフィルタを入力するだけで、古いフィルタが更新されます。現在、サポートされているフィルターは 1 つだけです。将来的には複数のフィルターがサポートされる可能性があります。
/github subscribe owner/repo +label:"teams/designers"
既存のフィルターpriority:HIGH teams/designersに置き換えられました。
フィルターを削除するには、 unsubscribe必要があります。
/github unsubscribe owner/repo +label:teams/designers
これにより、 teams/designersフィルターが削除されます。
現在アクティブなフィルターを確認するには、次を使用します。
/github subscribe list features
ラベルに特定の特殊文字が含まれるのが一般的です。したがって、ラベル フィルターに最も一般的な特殊文字のサポートを追加しました。以下にいくつかの例を示します。
label:"priority:HIGH"label:"teams/designers"label:"DO NOT MERGE"label:"very important"label:":construction: WIP"ほとんどのラベルはシームレスに機能します。これには、Slack と Github がすぐに提供するすべての絵文字が含まれます。ただし、次のようなまれな状況では、問題が発生する可能性があります。
:foo:としてエンコードされていないマルチバイト文字,予約されています「ワークフロー」機能を使用して、チャネルまたは個人アプリから GitHub Actions ワークフロー実行通知をサブスクライブできます。
ワークフローの実行通知をすべて受け取ると、煩わしい場合があります。そのため、要件に基づいて通知をフィルタリングする機能を提供しています。名前、イベント、アクター、ブランチに基づいてアクション ワークフロー通知をフィルターできます。以下のように通知をフィルタリングできます。
/github subscribe owner/repo workflows:{name:"your workflow name" event:"workflow event" branch:"branch name" actor:"actor name"}
以下の例のように、各イベントの複数のエントリをカンマ区切りのリストとして渡すことができます: /github subscribe org/repo workflows:{event:"pull_request","push" branch:"main","dev" actor:"ashokirla"}
デフォルトでは、フィルターを渡さずにワークフロー通知を構成すると、デフォルトのブランチをターゲットとするプル リクエストによってトリガーされるワークフロー用に構成されます。 1 つまたは複数のエントリを渡すことができます。
次のコマンドを実行するだけで、ワークフロー通知のサブスクライブを解除できます: /github unsubscribe org/repo workflows
上記の通知を受信するには、Slack の GitHub アプリでアクション イベントを受信するためのアクセスを許可する必要があります。組織のworkflows機能を初めてサブスクライブしようとすると、サブスクライブするように求められます。
導入に対する個別の通知をサポートしています。これらのデプロイメントは、アクションから、またはデプロイメント API を使用して外部ソースから実行できます。
この機能を有効または無効にするには、次のコマンドを実行します。
/github subscribe/unsubscribe org/repo deployments
注: GitHub アクションを使用していて、環境へのデプロイメントを追跡したい場合は、代わりに新しいworkflows機能を使用することをお勧めします。この機能により全体像が表示され、デプロイメントをその場で承認できるようになります。
Slack でリポジトリを購読すると、通知の中で自分が参照され、注意が必要な場所に自分の名前が記載されるようになります。
問題、PR、展開に関する通知を受け取るときに、あなたが言及されるケースは次のとおりです。
そして最も良い点は、Slack の「メンションとリアクション」セクションの一部として自分が言及されている GitHub 通知の概要を確認できることです。
メンションは、Slack ワークスペースで GitHub アプリにログインした場合にのみ機能します ( /github signinスラッシュ コマンドを使用)。 GitHub ID を使用して GitHub アプリにログインすると、GitHub ID が Slack ID にマッピングされ、GitHub 通知のいずれかで言及されるたびに Slack に ping が送信されます。
注: GitHub アプリを使用する Slack ワークスペースが複数ある場合、メンションは最後に GitHub アプリにログインしたワークスペースでのみ機能します。
問題と PR の通知は、返信として親カードの下にグループ化されます。親カードには、タイトル、説明、譲受人、査読者、ラベル、チェックなどの他のメタデータとともに、問題/PR の最新のステータスが常に表示されます。スレッド化によりコンテキストが提供され、チャネル内のコラボレーションが向上します。
これにより、チャネル内のノイズが軽減されます。また、メンション機能により、会話スレッドに参加している人のみに通知が届きます。親カードのみがチャネルに投稿され、残りの通知はスレッド内の返信として追加されます。ただし、クローズ/再オープンの問題などの状態変更アクティビティは、グループにとって興味深い可能性があるため、返信としてスレッドに追加され、チャネルにも投稿されます。
コメントとレビューの通知を購読しており、問題の参加者だけでなくチャンネルのメンバーにも通知を表示したい場合は、次のコマンドを実行して同じようにオプトインできます。
/github subscribe org/repo comments:"channel"および
/github subscribe org/repo reviews:"channel"
注: デフォルトでは、コメントとレビューはスレッドにのみ表示されます。また、上記のコマンドを明示的に実行して、コメントがチャンネルにも確実に流れ込むようにする必要があります。
あなたがコメントで言及された問題/情報に参加している場合、または担当者/レビュー担当者として追加されている場合、メンション機能により、Slack のスレッド セクションで通知が確実に届きます。注意が必要な問題や宣伝のためにチャンネルにアクセスする必要はありません。必要な部分に集中することができ、スレッド機能により全体像を確実に把握し、そこから直接アクションを起こすことができます。これは、注意が必要な問題や情報を見逃さないようにする非常に強力な機能です。
ただし、スレッド内で問題や PR の更新を表示する必要はなく、それがノイズであると絶対に確信している場合は、スレッドへの ping やエントリをこれ以上行わないための簡単な回避策を提案できます。 GitHub アプリは、最後に GitHub にログインした Slack ワークスペース内でのみあなたをメンションします。最も使用されていない Slack ワークスペースまたは個人用 Slack ワークスペースに移動し、そこから GitHub アプリを使用して GitHub にログインできます。そうすれば、ping が送信されなくなり、他のメイン ワークスペースのスレッドで更新が表示されなくなります。
スレッド機能が必要ない場合、または新しいモデルに適応する準備がまだ整っていない場合でも、柔軟性を提供したいと考えています。チャンネル内の課題とプル リクエストの通知のスレッドを無効または有効にすることができます。スレッド化が必要ないチャネルに移動して、次のコマンドを実行できます。 /github settings
そのチャネルのスレッドを無効/有効にするオプションが表示されます。チャンネルに参加しているメンバーは誰でもこのアクションを実行できます。
Slack での会話は、多くの場合、意思決定や実用的な結論につながります。 Slack から次のステップに簡単に着手できるようになりました。
問題に対してアクションを実行するために GitHub に切り替えたりリダイレクトしたりする必要はなくなりました。コラボレーションする場所、つまり Slack から実際に問題を作成および管理できます。
共同作業している場所から、クリックするだけで問題を作成できるようになりました。どのチャネル/個人アプリ/グループでも、ダイレクト チャットでも、メッセージの右上隅にある 3 つの点 (...) をクリックし、リストから [Create an Issue GitHub] を選択できるようになりました。これにより、問題の作成ダイアログが起動します。
あるいは、他の 2 つの方法で Slack から問題を作成することもできます。
/github openコマンドを実行して、問題の作成フローを起動することもできます。 
注: アクションを実行するには、サインインし、リポジトリに必要なアクセス権を持っている必要があります。
問題のライフサイクルをチャットから直接管理することもできます。リポジトリを購読して課題通知を受け取るとき、または Slack から新しい課題を作成するときに、CTA ボタンのコメント、編集、閉じる/再開するボタンを備えた課題カードが表示されるようになります。これらのアクションはチャットから直接実行できます。
注: Slack から課題カードに対してアクションを実行すると、サブスクリプションを通じてそのアクティビティにサブスクライブしていない場合でも、応答がスレッドへの返信として追加されます。ただし、購読すると、Slack の外部で発生したアクティビティの通知も受け取ることになります。
ユーザーが、Slack の課題やプル リクエスト、直接リンクされたコメント、行番号付きのコードBLOB 、組織、リポジトリ、ユーザーへの GitHub リンクを投稿すると、リンクのプレビューが表示されます。
次の場合、リンクのプレビューは表示されません。
github.comのリンク プレビューがワークスペースで無効になっています/invite @githubで解決できますスケジュールされたリマインダーは、ユーザーが注意を必要とする最も重要なレビュー要求に集中できるようにするために使用されます。プル リクエストのスケジュールされたリマインダーにより、指定された時間に、レビューが必要なオープンなプル リクエストを含むメッセージが Slack に送信されます。たとえば、スケジュールされたリマインダーを設定して、毎朝午前 10 時に Slack で自分またはチームのいずれかによるレビューが必要なプル リクエストのメッセージを送信することができます。
自分、チーム、組織向けにスケジュールされたリマインダー (個人リマインダー) を設定できます。
個人のスケジュールされたリマインダーは、Slack の GitHub 個人アプリの一部として構成されます。メンバーとなっている組織のプル リクエストに対する個人レベルまたはチーム レベルのレビュー リクエストに対して、スケジュールされたリマインダーを設定できます。個人的なリマインダーの一部として、プル リクエストのリアルタイム アラートを構成することもできます。詳細については、こちらをご覧ください。
保留中のプル リクエストのスケジュールされたリマインダーを Slack チャネルの一部として構成できるため、チームは常に作業を把握できます。特定の Slack チャネルに対して、組織またはチーム向けにスケジュールされたリマインダーを構成できます。スケジュールされたリマインダーの構成の詳細については、組織レベルのリマインダーとチーム レベルのリマインダーを参照してください。
Slack Enterprise Grid を使用していて、組織内に GitHub を使用する必要がある複数の Slack ワークスペースがある場合は、GitHub アプリを Slack Enterprise Grid にインストールして管理できます。 Slack Enterprise グリッドの組織所有者と組織管理者は次のことができます。
ワークスペースのメンバーからの GitHub アプリのインストール リクエストを管理します。
今後のすべてのワークスペースで GitHub アプリをデフォルトで利用できるようにします。
Enterprise Grid 組織管理者と組織所有者のみが、GitHub アプリをグリッド レベルでインストールして管理できます。
ここをクリックして、インストールするエンタープライズ グリッド組織を選択することで、GitHub アプリを組織レベルでインストールできます。
GHES 3.8 による GHES と Slack の統合の GA を発表します。
この統合により、GHES インスタンスのリポジトリにサブスクライブし、Slack で問題、PR、コミット、デプロイメントに関するライブ更新を取得できるようになります。また、Slack から直接コメントしたり、問題を開いたり閉じたり、展開を承認したりすることもできます。
GHES 3.8 以降、専用の ChatOps サービスが GHES サーバーにバンドルされて出荷されます。また、Slack ワークスペースとの統合を選択することもできます。 GHES との統合により、次のことが可能になります。
完全に安全でスケーラブルなエクスペリエンス: すべてのサブスクリプション情報とその他のメタデータは GHES セットアップ内に残ります。したがって、外部サービスへのデータの流れを心配する必要はありません。
GHES と Slack 間の双方向接続: 当社の GHES 統合は単なる通知サービスではありません。また、チャットから直接アクションを実行できるようになります。したがって、GHES インスタンスが Slack からアクセスできることを確認するために必要な唯一の前提条件があります。ソケット モードを有効にすると、Slack からの受信アクセスのみが必要になります。
アプリ ストアにある既存の GitHub アプリは、GHEC (ホスト型 GitHub) 統合にのみ使用できます。 GHES インスタンスを Slack と統合するには、プライベート GHES アプリを構成する必要があります。 GHES と統合する手順は次のとおりです。
<instancename>/_slack/またはslack.<instancename>のいずれかに移動して、ワークスペースにアプリをインストールします。
プロキシは現在サポートされていません。
ご質問やご不明な点がございましたら、ここに問題を記録してご連絡ください。または、GitHub のサポート フォームにご記入ください。リクエストは GitHub の適切なチームにルーティングされます。
| このリポジトリはコードの寄稿を受け付けていません。 GitHub と Slack の統合で実行されている現在のコードは、GitHub インフラストラクチャでサービスを実行するために必要であり、現時点ではオープンソース化できない特定のコードが含まれているため、このリポジトリに存在するコードとは大きく異なります。私たちは今後もこのリポジトリの問題を使用して、顧客からフィードバックを得る予定です。 |
このプロジェクトは、MIT ライセンスの条件に基づいてオープン ソースとして利用できます。
GitHub ロゴを使用する場合は、必ず GitHub ロゴのガイドラインに従ってください。
