Enterprise Server 3.15 は、現在リリース候補として使用できます。

Projects (Classic) で割り当てられた問題を移動する

GitHub Actions を使用して、Issue が割り当てられたときに、Project (Classic) の特定の列に Issue を自動的に移動できます。

この記事の内容

Note

  • 新しいプロジェクト エクスペリエンスである Projects が利用できるようになりました。 Projects の詳細については、「Projects について」を参照してください。
  • 新しいProject (Classic)は、既に 1 つ以上のProject (Classic)を持つ organization、リポジトリ、またはユーザーに対してのみ作成できます。 Project (Classic)を作成できない場合は、代わりにプロジェクトを作成します。

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

はじめに

このチュートリアルでは、alex-page/github-project-automation-plus アクションを使用し、Issue が割り当てられているとき、Project (Classic) で特定の列に Issue を自動的に移動する方法について説明します。 たとえば、Issue が割り当てられたら、それを Project (Classic) の In Progress 列に移動できます。

チュートリアルでは、alex-page/github-project-automation-plus アクションを使用するワークフロー ファイルをまず作成します。 次に、ニーズに合わせてワークフローをカスタマイズします。

ワークフローの作成

  1. このプロジェクト管理ワークフローを適用したいリポジトリを選択してください。 書き込みアクセス権を持つ既存のリポジトリを利用することも、新しいリポジトリを作成することもできます。 リポジトリの作成について詳しくは、「新しいリポジトリの作成」をご覧ください。

  2. リポジトリの Project (Classic) を選択します。 既存のプロジェクトを使用することも、新しいプロジェクトを作成することもできます。 プロジェクトの作成に関する詳細については、「project (classic) の作成」を参照してください。

  3. リポジトリに .github/workflows/YOUR_WORKFLOW.yml というファイルを作成します (YOUR_WORKFLOW は任意の名前に置き換えます)。 これがワークフローファイルです。 GitHub で新しいファイルを作成する方法について詳しくは、「新しいファイルの作成」を参照してください。

  4. 次の YAML コンテンツをワークフローファイルにコピーします。

    YAML
    # このワークフローはGitHubによって認定されていないアクションを使用します。
# それらはサードパーティによって提供され、
# 別個の利用規約、プライバシーポリシー、
# ドキュメントを参照してください。

# GitHub では、コミット SHA にアクションをピン留めすることが推奨されます。
# 新しいバージョンを取得するには、SHA を更新する必要があります。
# タグまたはブランチを参照することもできますが、アクションは警告なしに変更される可能性があります。

name: Move assigned card
on:
  issues:
    types:
      - assigned
jobs:
  move-assigned-card:
    runs-on: ubuntu-latest
    steps:
      - uses: alex-page/github-project-automation-plus@7ffb872c64bd809d23563a130a0a97d01dfa8f43
        with:
          project: Docs Work
          column: In Progress
          repo-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}

  5. ワークフローファイルのパラメータをカスタマイズします。

    • project の値を Project (Classic) の名前に変更します。 名前が同じ Projects (Classic) が複数ある場合、alex-page/github-project-automation-plus アクションは指定の名前のすべてのプロジェクトで動作します。
    • column の値を、Issue が割り当てられたときに移動する列の名前に変更します。
    • 値の repo-token を変更します。
      1. repo スコープで personal access token (classic) を作成します。 詳しくは、「個人用アクセス トークンを管理する」を参照してください。
      2. この personal access token を自分のリポジトリにシークレットとして格納します。 シークレットの保管の詳細については、「GitHub Actions でのシークレットの使用」を参照してください。
      3. ワークフロー ファイルで、PERSONAL_ACCESS_TOKEN をシークレットの名前に置き換えます。

  6. ワークフローファイルを、リポジトリのデフォルトブランチにコミットしてください。 詳しくは、「新しいファイルの作成」を参照してください。

ワークフローのテスト

リポジトリで Issue が割り当てられるたびに、その Issue は指定された Projects (Classic) 列に移動されます。 問題が Project (Classic) にまだ存在しない場合は、Project (Classic) に追加されます。

リポジトリがユーザー所有の場合、alex-page/github-project-automation-plus アクションは、指定されたプロジェクト名と列を持つリポジトリまたは個人アカウント内のすべてのプロジェクトに対して動作します。 同様に、リポジトリが Organization 所有の場合、アクションは、指定されたプロジェクト名と列を持つリポジトリまたは Organization 内のすべてのプロジェクトに対して動作します。

リポジトリに Issue を割り当てて、ワークフローをテストします。

  1. リポジトリで Issue をオープンします。 詳しくは、「Issue の作成」を参照してください。
  2. Issue を割り当てます。 詳しくは、「GitHub の他のユーザに Issue およびプルリクエストをアサインする」を参照してください。
  3. トリガーされた Issue を割り当てるワークフローの実行を確認するには、ワークフローの実行履歴を表示します。 詳しくは、「ワークフロー実行の履歴を表示する」を参照してください。
  4. ワークフローが完了したら、割り当てた Issue を指定された Projects (Classic) 列に追加する必要があります。

次のステップ