長く運用しているプロジェクトでは、
- Node.js
- PHP
- Java
- Python
- Ubuntu
など、利用しているランタイムのサポート終了（EOL）が必ずやってきます。
普段は問題なく動いていても、
- セキュリティアップデートが提供されない
- CI環境が古いままになる
- ライブラリが対応しなくなる
といったリスクがあります。
そこで、GitHub Actionsを利用し、EOLが近づいたランタイムを定期的にチェックし、Backlogへチケットを自動作成する仕組みを構築しました。
なぜ導入したのか
以前は、
「そろそろNode.jsを上げた方がいい」
という情報共有だけで終わることが多く、
結局対応が後回しになることも少なくありませんでした。
そこで、
通知だけではなく、
対応タスクまで自動で作成する
ことにしました。
全体構成
GitHub Actions
↓
endoflife.date API
↓
EOL判定
↓
Backlog API
↓
課題作成
GitHub Actions
毎週月曜日に実行しています。
name: Runtime EOL Check
on:
schedule:
- cron: "0 1 * * 1"
workflow_dispatch:
手動実行にも対応しています。
Workflow例
name: Runtime EOL Check
on:
schedule:
- cron: "0 1 * * 1"
workflow_dispatch:
jobs:
eol-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check Node.js EOL
run: |
python scripts/check_eol.py
env:
BACKLOG_API_KEY: ${{ secrets.BACKLOG_API_KEY }}
BACKLOG_PROJECT_ID: ${{ secrets.BACKLOG_PROJECT_ID }}
Pythonスクリプト内で、
- EOL情報取得
- 判定
- Backlog API呼び出し
まで行っています。
EOL情報取得
EOL情報は
endoflife.date
を利用しています。
例えばNode.jsなら、
curl https://endoflife.date/api/nodejs.json
だけで取得できます。
PHPやUbuntuなども同じAPIで確認できます。
Backlog API
EOLが近い場合だけ、
Backlogへ課題を作成します。
例
件名
Node.js 20 のEOL対応
内容
Node.js 20は30日後にサポート終了予定です。
対応内容
・アップグレード方針の確認
・ライブラリ互換性調査
・CI更新
Python例
import requests
requests.post(
"https://xxx.backlog.jp/api/v2/issues",
params={
"apiKey": BACKLOG_API_KEY,
"projectId": BACKLOG_PROJECT_ID,
"summary": "Node.js 20 のEOL対応",
"issueTypeId": ISSUE_TYPE_ID,
"priorityId": 3,
"description": "Node.js 20のサポート終了が近づいています。"
}
)
Secrets
Backlog APIキーは
GitHub Secretsで管理しています。
BACKLOG_API_KEY
BACKLOG_PROJECT_ID
BACKLOG_ISSUE_TYPE_ID
Workflowへ直接記載することはありません。
対象
現在は、
- Node.js
- PHP
- Ubuntu
を監視しています。
必要に応じて、
- Java
- Python
- PostgreSQL
- MySQL
なども追加できます。
重複チケット対策
毎週実行すると、
同じ課題が何度も作成されてしまいます。
そのため、
Backlog APIで既存課題を検索し、
未対応のチケットが存在する場合は新規作成しないようにしています。
EOL判定
↓
Backlog検索
↓
課題あり
↓
終了
↓
課題なし
↓
新規作成
導入して感じたこと
通知だけでは、
「あとで対応しよう」
となりがちでした。
一方、
Backlogへ課題が登録されると、
通常の開発タスクと同じように管理できます。
そのため、
EOL対応が後回しになることが減りました。
まとめ
今回構築した仕組みでは、
- GitHub Actionsで定期実行
- endoflife.date APIからEOL情報取得
- 利用中のランタイムと比較
- Backlog APIで課題作成
- 重複課題は作成しない
という流れにしています。
EOL対応は緊急度が低く見えますが、対応が遅れるとセキュリティや保守性に影響します。
GitHub ActionsとBacklogを組み合わせることで、EOLの検知からタスク化までを自動化でき、計画的なバージョンアップにつなげられるようになりました。