注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。
はじめに
このチュートリアルでは、imjohnbo/issue-bot
アクションを使用して定期的に Issue を作成する方法について説明します。 たとえば、Issue を毎週作成して Team 会議のアジェンダとして使用できます。
チュートリアルでは、imjohnbo/issue-bot
アクションを使用するワークフロー ファイルをまず作成します。 次に、ニーズに合わせてワークフローをカスタマイズします。
ワークフローの作成
-
このプロジェクト管理ワークフローを適用したいリポジトリを選択してく� さい。 書き込みアクセス権を持つ既存のリポジトリを利用することも、新しいリポジトリを作成することもできます。 リポジトリの作成の詳細については、「新しいリポジトリの作成」を参照してく� さい。
-
リポジトリに
.github/workflows/YOUR_WORKFLOW.yml
というファイルを作成します (YOUR_WORKFLOW
は任意の名前に置き換えます)。 これがワークフローファイルです。 GitHub での新しいファイルの作成の詳細については、「新しいファイルの作成」を参照してく� さい。 -
次の YAML コンテンツをワークフローファイルにコピーします。
YAML # このワークフローはGitHubによって認定されていないアクションを使用します。 # それらはサードパーティによって提供され、 # 別個の利用規約、プライバシーポリシー、 # ドキュメントを参照してく� さい。 # GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。 # 新しいバージョンを取得するには、SHA を更新する必要があります。 # タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。 name: Weekly Team Sync on: schedule: - cron: 20 07 * * 1 jobs: create_issue: name: Create team sync issue runs-on: ubuntu-latest permissions: issues: write steps: - name: Create team sync issue uses: imjohnbo/issue-bot@3daae12aa54d38685d7ff8459fc8a2aee8cea98b with: assignees: "monalisa, doctocat, hubot" labels: "weekly sync, docs-team" title: "Team sync" body: | ### Agenda - [ ] Start the recording - [ ] Check-ins - [ ] Discussion points - [ ] Post the recording ### Discussion Points Add things to discuss below - [Work this week](https://github.com/orgs/github/projects/3) pinned: false close-previous: false env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-
ワークフローファイルのパラメータをカスタマイズします。
on.schedule
の値を変更して、このワークフローを実行する日時を指定します。 上記の例では、ワークフローは毎週月曜日の 7:20 UTC に実行されます。 スケジュールされたワークフローの詳細については、スケジュールされたイベントに関するページを参照してく� さい。assignees
の値を、Issue に割り当てる GitHub のユーザー名のリストに変更します。labels
の値を、Issue に適用するラベルのリストに変更します。title
の値を、Issue のタイトルに変更します。body
の値を、Issue の本文のテキストに変更します。|
文字を使用すると、このパラメーターに複数行の値を使用できます。- この Issue をリポジトリにピン止めする� �合は、
pinned
をtrue
に設定します。 ピン留めされた Issue の詳細については、「Issue をリポジトリにピン止めする」を参照してく� さい。 - 新しい Issue が作成されるたびにこのワークフローで生成された以前の Issue をクローズする� �合は、
close-previous
をtrue
に設定します。 ワークフローにより、labels
フィールドで定義されているラベルを持つ最新の Issue が閉じられます。 間違った Issue をクローズしないようにするには、一意のラベルまたはラベルの組み合わせを使用します。
-
ワークフローファイルを、リポジトリのデフォルトブランチにコミットしてく� さい。 詳細については、「新しいファイルの作成」を参照してく� さい。
予想される結果
schedule
パラメーター (たとえば、毎週月曜日の 7:20 UTC) に基づき、ワークフローにより、指定した担当者、ラベル、タイトル、本文を使用して新しい Issue が作成されます。 pinned
を true
に設定すると、ワークフローによって Issue がリポジトリにピン留めされます。 close-previous
を true に設定すると、ワークフローによりラベルが一致する最新の Issue がクローズされます。
注: GitHub Actions のワークフローの実行によって高い� 荷がかかっている間、schedule
イベントが遅延する可能性があります。 高� 荷の時間帯には、毎時の開始時点が含まれます。 遅延の可能性を減らすために、� 時間の中の別の時間帯に実行されるようワークフローをスケジューリングしてく� さい。
ワークフローの実行履歴を表示して、このワークフローが定期的に実行されているかどうかを確認できます。 詳細については、「ワークフロー実行の履歴を表示する」を参照してく� さい。
次のステップ
- 担当者のローテーションや Issue テンプレートの使用など、
imjohnbo/issue-bot
アクションで実行できる他の操作の詳細については、imjohnbo/issue-bot
アクションのドキュメントを参照してく� さい。 - このアクションを使用するワークフローの例については GitHub を検索してく� さい。