## はじめに

GitHub Actions を利用する際、似たような処理を何度も記述していませんか？ ワークフローが複雑になるにつれて、メンテナンスコストが増大し、変更への対応も煩雑になりがちです。 
この記事では、GitHub Actions の処理を共通化することで、これらの問題を解決するための手法を、具体的な例を交えながら解説します。

## 再利用可能なワークフローによる共通化

まずは、<a href="https://docs.github.com/ja/actions/sharing-automations/reusing-workflows" target="_blank" rel="noopener noreferrer">ワークフローの再利用</a>を活用した共通化の方法を説明します。

**on** キーワードで、ワークフローを直接トリガーするイベントの代わりに **workflow_call** イベントを指定すると、別のワークフローからそのワークフローを呼び出すことができます。

**例: .github/workflows/deploy.yml**

```yaml
name: Deploy to Production

on:
 workflow_call: # ワークフローを再利用可能にするイベント
 inputs: # 呼び出し元のワークフローからパラメータを受け取る
 environment:
 required: true
 type: string
 target_host:
 required: true
 type: string

 secrets: # シークレットを受け渡す場合は明示的に指定する必要がある
 SSH_PRIVATE_KEY:
 required: true

 outputs: # 処理結果を呼び出し元のワークフローに返す
 deployment_status:
 description: "The status of the deployment job"
 value: ${{ jobs.deploy.outputs.status }}

jobs:
 deploy:
 runs-on: ubuntu-latest
 outputs:
 status: ${{ job.status }}
 steps:
 - name: Checkout code
 uses: actions/checkout@v4
 - name: Set up SSH
 run: |
 mkdir -p ~/.ssh
 echo "${{ secrets.SSH_PRIVATE_KEY }}" | tr -d '\r' > ~/.ssh/id_rsa
 chmod 600 ~/.ssh/id_rsa
 ssh-keyscan -H ${{ inputs.target_host }} >> ~/.ssh/known_hosts
 - name: Deploy to server
 run: rsync -avz -e "ssh -i ~/.ssh/id_rsa" ./ ${{ inputs.environment }}@${{ inputs.target_host }}:/var/www/html
```

上記のワークフローを呼び出すには、以下のように記述します。 
**jobs** セクションで新しいジョブを定義し、そのジョブ内で **uses** キーワードを使って、再利用可能なワークフローのパスを指定します。

**例: .github/workflows/deploy.yml**

```yaml
name: Deploy Application

on:
 push:
 branches: [main]

jobs:
 deploy-staging:
 uses: ./.github/workflows/deploy.yml # 共通化したワークフローのパス
 with: # 呼び出し元の inputs で定義した値を渡す
 environment: "staging"
 target_host: "staging.example.com"
 secrets: # 呼び出し元の secrets で定義した値を渡す
 SSH_PRIVATE_KEY: ${{ secrets.STAGING_SERVER_SSH_KEY }}

 deploy-production:
 uses: ./.github/workflows/deploy.yml
 with:
 environment: "production"
 target_host: "prod.example.com"
 secrets:
 SSH_PRIVATE_KEY: ${{ secrets.PRODUCTION_SERVER_SSH_KEY }}

 post-deployment-check:
 needs: [deploy-staging, deploy-production]
 runs-on: ubuntu-latest
 steps:
 - name: Check deployment status
 # 呼び出し元の outputs で定義した値を受け取る
 run: |
 echo "Staging deployment status: ${{ jobs.deploy-staging.outputs.deployment_status }}"
 echo "Production deployment status: ${{ jobs.deploy-production.outputs.deployment_status }}"
```

## Composite Action による共通化

次に、<a href="https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action" target="_blank" rel="noopener noreferrer">Composite Action</a> を活用した共通化の方法を説明します。

Composite Action は、通常のワークフローとは異なり、フォルダ階層は自由ですが、ファイル名は **action.yml** にする必要があります。 <a href="https://www.google.com/search?q=https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action%23creating-a-composite-action-within-the-same-repository" target="_blank" rel="noopener noreferrer">GitHub Docs</a> では、**.github/actions/{任意の名前}/action.yml** というフォルダ構成で作成することが推奨されています。

また、現時点では secrets の受け渡しはできません。 <a href="https://www.google.com/search?q=https://github.com/actions/runner/blob/main/docs/adrs/0549-composite-run-steps.md%23secrets" target="_blank" rel="noopener noreferrer">今後サポートされる予定</a> のようです。

**例: .github/actions/test/action.yml**

```yaml
name: "Node.js Test"
description: "Test implemented in node.js"
inputs: # 呼び出し元のワークフローからパラメータを受け取る
 working-directory:
 description: "Path to the working directory"
 required: true

outputs: # 処理結果を呼び出し元のワークフローに返す
 test_report_path:
 description: "Path to the test report file (if generated)"
 value: ${{ steps.report.outputs.test_report_path }}

runs:
 using: "composite" # Composite Action であることを宣言
 steps:
 - name: Checkout code
 uses: actions/checkout@v4

 - name: Set up Node.js ${{ inputs.node_version }}
 uses: actions/setup-node@v4
 with:
 node-version: 22.X

 - name: Install dependencies
 run: npm install
 shell: bash # コマンド実行には shell を明示的に指定する
 working-directory: ${{ inputs.working-directory }}

 - name: Run tests
 run: npm run test --report_output=./test-results.xml
 shell: bash
 working-directory: ${{ inputs.working-directory }}

 - name: Set test report output
 id: report
 run: echo "test_report_path=$(pwd)/test-results.xml" >> "$GITHUB_OUTPUT"
 shell: bash
 working-directory: ${{ inputs.working-directory }}
```

上記の Composite Action を実行するには、以下のように記述します。

**例: .github/workflows/test.yml**

```yaml
name: Test Application

on:
 push:
 branches: [main]

jobs:
 test-app1:
 runs-on: ubuntu-latest
 steps:
 - name: Test
 id: test
 uses: ./.github/actions/test # 実行する Composite Action のディレクトリ
 with:
 working-directory: "./app1" # 呼び出し元の inputs で定義した値を渡す

 - name: Output test results
 # 呼び出し元の outputs で定義した値を受け取る
 run: cat ${{ steps.test.outputs.test_report_path }}

 test-app2:
 runs-on: ubuntu-latest
 steps:
 - name: Test
 id: test
 uses: ./.github/actions/test
 with:
 working-directory: "./app2"

 - name: Output test results
 run: cat ${{ steps.test.outputs.test_report_path }}
```

## どちらの方法を選ぶべきか

再利用可能なワークフローは、ワークフロー全体を共通化する仕組みです。 GitHub Actions は job 単位で別々のコンテナで実行されるため、共通処理内で変更した内容 (生成したファイルやインストールしたパッケージなど) は、後続の処理に引き継ぐことができません。

一方、Composite Action は step 単位で共通化するため、共通処理内で変更した内容は後続の処理に引き継がれます。 また、再利用可能なワークフローは実行のたびに新しいコンテナを立ち上げる必要があるため、単純で実行回数の多い処理の場合は Composite Action を利用することで、処理時間の短縮と料金の節約につながります。

以上の点を考慮すると、以下のように使い分けるのが適切です。

**再利用可能なワークフロー**

- 共通処理内で変更した内容を後続の処理に引き継ぐ必要がない場合（例: ビルド、デプロイ処理、セキュリティスキャンなど）
- 環境を変えて (Node.js のバージョンなど) 共通処理を実行する場合

**Composite Action**

- 共通処理内で変更した内容を後続の処理に引き継ぐ必要がある場合（例: 依存関係のインストール、環境設定、複数のコマンド実行など）
- 単純または実行回数の多い処理（例: テスト結果やデプロイ結果の出力、チャット通知など）

## まとめ

この記事では、GitHub Actions におけるワークフローの共通化手法として、再利用可能なワークフローと Composite Action の 2 つを紹介しました。

どちらの手法を選択するかは、共通化したい処理の粒度や、処理内で変更した内容を後続の処理で利用する必要があるかどうかなどを考慮して判断する必要があります。 これらの手法を適切に活用することで、ワークフローのメンテナンス性を向上させ、開発効率を高めていきましょう！

## 参考サイト

- <a href="https://docs.github.com/ja/actions/sharing-automations/reusing-workflows" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/sharing-automations/reusing-workflows</a>
- <a href="https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action" target="_blank" rel="noopener noreferrer">https://docs.github.com/ja/actions/sharing-automations/creating-actions/creating-a-composite-action</a>
- <a href="https://zenn.dev/moaikids/articles/32363c5386978e" target="_blank" rel="noopener noreferrer">https://zenn.dev/moaikids/articles/32363c5386978e</a>
- <a href="https://zenn.dev/kinjosan/articles/bd82e07aa69080" target="_blank" rel="noopener noreferrer">https://zenn.dev/kinjosan/articles/bd82e07aa69080</a>

small_github.png

thumbnail_github.png

github.png

GitHub Actions 共通化手法

今回は、GitHubの便利機能の紹介です！ 
⚠️現時点ではPublic Previewの機能紹介になります 


## こんな人向け

- 大規模なタスク/プロジェクトを分割して管理したい
- 分割したタスクを一目で進捗を見えるようにしたい

⚠️組織(organization)アカウントの人しか使えません


## Sub-Issues機能
GitHubでは、Issueに親子関係を作成することができ、Sub-Issue を Issue に追加することで、大きな作業をタスクに分割できます。 
Sub-Issue は、親の Issue との関係が表示されるため、GitHub 全体で作業を追跡できます。 
これにより、ビューの作成、親の問題によるフィルター処理、グループ化を行うことができます。

Sub-Issue 自体に Sub-Issue を含めることができるため、プロジェクト全体または作業の一部を視覚化し、Issue 間の関係を示す Issue の完全な階層を作成できます。

親 Issue ごとに最大 100 個のサブ Issue を追加でき、最大 8 レベルの入れ子になったサブ Issue を作成できます。 
つまり、最大100の8乗個のIssueを管理できます。

## Sub-Issueの作成手順
1. Issue画面の「Create Sub-Issue」から子Issueを作成できます。
2. Issue の説明の下部にある、[Sub-Issue の作成] をクリックします。
 
 ![](https://cont.sterfield.co.jp/uploads/1_a946d23684.png) 
3. テンプレートが準備されている場合には、ダイアログで、Issue のテンプレートを選択できます。
 
 ![](https://cont.sterfield.co.jp/uploads/2_fc9a7ceff4.png) 

4. 必要に応じて、Issueの情報を入力し、Issue の種類を設定し、 担当者、ラベル、プロジェクト、マイルストーンを設定します。 
 ![](https://cont.sterfield.co.jp/uploads/3_66a99f2eb1.png) 
## 既存の Issue を Sub-Issue として追加する方法
1. Issue画面の「Add existing Issue」から子Issueを作成できます。 
 ![](https://cont.sterfield.co.jp/uploads/4_cb14540079.png) 
2. Sub-Issue として追加する問題を選択します。
 ・提案の 1 つから Issue を選択します。
 ・[Issue の検索] フィールドに、Issue のタイトルまたは Issue 番号を入力し、結果をクリックします。
 ・他のリポジトリから Issue を追加するには、リポジトリ名の横にある をクリックし、別のリポジトリを選択します。
 ![](https://cont.sterfield.co.jp/uploads/5_59fafbf05a.png) 
子Issueが登録された親Issueには、子Issueの進捗状況が表示されます。 
 ![](https://cont.sterfield.co.jp/uploads/6_d5394fd099.png) 
 ![](https://cont.sterfield.co.jp/uploads/7_7c52dd58b2.png) 

## Sub-Issueの解除手順
1. Issue画面の解除したいSub-Issue横の[…]をクリックします。
2. 「Remove Sub-Issue」をクリックする
 ![](https://cont.sterfield.co.jp/uploads/8_c6aa8fc7e9.png) 
## まとめ
今までもISSUEの概要に書いたタスクリストからISSUEを生成する機能がありましたが、Sub-Issue機能の方がIssue同士のリレーションがしっかりしているので、確認する際に迷子になりづらい点がgoodです◎ 
そんな理由で、GitHubをチームで利用しているなら、必ず使ったほうがいい機能だと思いました。 
個人的には、Sub-Issue作ったタイミングで、自動的に親Issueに紐づいてくれたらいいのに。と思ったりしました（笑）

small_pixta_50037742_S.jpg

thumbnail_pixta_50037742_S.jpg

pixta_50037742_S.jpg

GitHubの便利機能紹介シリーズ「Sub-Issue機能」

## はじめに
この記事では、GitHubのリポジトリからステータスが"OPEN"のIssueを取得し、Googleスプレッドシートに追記する方法を紹介します。GitHubのREST APIを使用し、Google Apps Scriptを使って自動化します。これにより、特定の組織の複数のリポジトリからIssue情報を一括で取得し、追加の作業なしでスプレッドシートに保存できます。

ということで、前回の記事でGoogle Apps Script（GAS）をChatGPTに書いてもらったのですが、さまざまなことができることが分かったので、実際に業務で使っているGitHubとの連携を試してみました。
いくつか課題は残ったものの基本的な動作は確認できたのでそのGASそのものもシェア致します。

https://sterfield.co.jp/blog/18162/

## 必要なもの

### GitHubアカウントとアクセストークンの作成
 ![](/uploads/Fine_grained_Personal_Access_Tokens_861a8dbc65.png) 
GitHub >Setting>Developer Settings> personal access tokens >Fine-grained tokens
を選択します。
ここから新しいトークンを発行するのですが、我々の管理では、リポジトリは組織に紐づいているので、組織に対してのトークンと必要な権限、リポジトリのIssueの読み取り権限を設定します。

### Googleスプレッドシートの作成
最後にGASを共有していますが、スプレッドシートのIDが必要になります。
以下のようにd/と/editの間のXXXの値がスプレッドシートのIDになるので、控えておきしょう。

`https://docs.google.com/spreadsheets/d/XXX/edit` 

### Google Apps Scriptのセットアップ
 ![](/uploads/Chat_GPT_GAS_Google_1_8c0845570a.png) 
スプレッドシート＞拡張機能＞Apps Scriptで開いたページのコード.gs欄にベタっと貼り付けます。

## リポジトリの取得

ここから先のコードは、全てChatGPTから取得した末尾にシェアしているものを記載します。

GitHubのREST APIを使用して指定した組織のリポジトリを取得する関数を作成する
リポジトリの一覧を表示するためのスプレッドシートの作成

## Issueの取得と追記

取得したリポジトリごとにステータスが"OPEN"のIssueを取得する関数を作成する
スプレッドシートにIssue情報を追記する

## 実行と結果確認

Google Apps Scriptの実行方法とトリガーの設定
スクリプトを実行し、Issue情報がスプレッドシートに追記されることを確認する

以下のように、取得はできたものの課題を残す結果となったので、課題点は後述します。

 ![](/uploads/Google_1c1a29f017.png) 


## エラーハンドリングの追加と問題解決のヒント
エラーが出たら、そのエラー文言をChatGPTに投げ、修正コードをもらっていくのですが、こんなお茶目な一面も。
 ![](/uploads/GAS_1ac28d726e.png) 

## 課題点

- 一度に取得できるIssueを増やす。ページングの実装なども追加したが、全件取得には至らなかった。この点は、GraphQLの書き方をChatGPTが提案してくれたが、どうにも上手くいかず、今回はREST APIでの手法となった。
- Projectsから課題を取得できないか。これは、Projectsがベータ版となっており、ChatGPTが2021年9月までの情報に留まっているため、断念。
- シート内の重複削除。そもそも全件取得が出来ていないので、未検証。

## まとめ
この記事では、GitHubのREST APIとGoogle Apps Scriptを活用して、GitHubリポジトリからステータスが"OPEN"のIssueを自動的に取得し、Googleスプレッドシートに追記する方法を紹介しました。これにより、開発チームやプロジェクト管理者は、リポジトリ内のオープンな課題を一元管理し、効果的に追跡することができます。さらに、自動化されたプロセスにより、作業の効率化とヒューマンエラーの軽減も期待できます。是非、この方法を試してみてください。

本当に革命的だなと思うのは、今までエンジニアに依頼するしかなかったような作業が非エンジニアである人間とChatGPTとの会話だけで出来てしまうところです。そして、このやり取りをしながら、指示を変えたりデバッグしていく作業はとても楽しいものでした。

そして、結構な時間をChatGPTと向き合ってきて、コツが分かってきたのですが、何かコードをもらう時に、一気に指示を出すのではなく、最初は最小単位で指示を出し、成功したら少しずつ機能を追加していくと、結局は近道です。
今回のケースですと、まずは、Githubから特定のリポジトリのIssueを取得。これが成功したら、ステータスをオープンに限定、複数のリポジトリから取得する、スプレッドシート側の重複をチェックするというように足していくと良かったです。

最後に今回のGASをシェアします。トークンやスプレッドシートのIDなどは、置き換えてください。 

## GAS

```
// カスタムメニューを作成する関数
function onOpen() {
 var ui = SpreadsheetApp.getUi();
 ui.createMenu('Custom Menu')
 .addItem('Fetch and Append Issues', 'fetchAndAppendIssues')
 .addToUi();
}
function fetchAndAppendIssues() {
 var organization = "your_organization"; // 組織名
 var spreadsheetId = "your_spreadsheet_id"; // スプレッドシートのID
 var sheetName = "your_sheet_name"; // 追加するシートの名前
 var status = "open"; // 取得するIssueのステータス
 var perPage = 100; // 1回のリクエストで取得するIssueの数（最大100件）

 var sheet = SpreadsheetApp.openById(spreadsheetId).getSheetByName(sheetName);

 var repositories = getRepositories(organization);
 var newData = []; // 新しいデータを格納する配列

 for (var i = 0; i < repositories.length; i++) {
 var repo = repositories[i];
 var page = 1; // ページ番号

 while (true) {
 var url = "https://api.github.com/repos/" + organization + "/" + repo + "/issues?state=" + status + "&per_page=" + perPage + "&page=" + page;
 var response = UrlFetchApp.fetch(url, {
 headers: {
 "Authorization": "Bearer YOUR_GITHUB_ACCESS_TOKEN" // GitHubのアクセストークン
 }
 });

 var issues = JSON.parse(response.getContentText());
 if (issues.length === 0) {
 break; // ページの結果が空ならループを終了
 }

 for (var j = 0; j < issues.length; j++) {
 var issue = issues[j];
 var title = issue.title;
 var number = issue.number;
 var createdAt = issue.created_at;
 var htmlUrl = issue.html_url;

 newData.push([title, number, createdAt, htmlUrl]); // 新しいデータを配列に追加
 }

 page++; // 次のページに進む
 }
 }

 if (newData.length > 0) {
 if (sheet.getLastRow() === 0) {
 sheet.getRange(1, 1, newData.length, newData[0].length).setValues(newData); // データを直接書き込む
 } else {
 sheet.getRange(sheet.getLastRow() + 1, 1, newData.length, newData[0].length).setValues(newData); // データを追記
 }
 }
}

function getRepositories(organization) {
 var url = "https://api.github.com/orgs/" + organization + "/repos";
 var response = UrlFetchApp.fetch(url, {
 headers: {
 "Authorization": "Bearer YOUR_GITHUB_ACCESS_TOKEN" // GitHubのアクセストークン
 }
 });

 var repositories = JSON.parse(response.getContentText());
 var repoNames = [];

 for (var i = 0; i < repositories.length; i++) {
 var repo = repositories[i];
 repoNames.push(repo.name);
 }

 return repoNames;
}
```

large__09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

medium__09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

small__09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

thumbnail__09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

_09b5edad-a516-4f8f-93d9-5632be519bcc.jpeg

GitHubリポジトリからIssueを取得してスプレッドシートに追記するGAS試作版を作ってみた

Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - タグ: #github

2025/05/16

2025/01/17

2023/07/14