CodeCommit で Renovate を動かして依存関係の更新 PR を自動作成してみた
CodeCommit で Renovate を動かしてみた
製造ビジネステクノロジー部の小林です。
最近ソースコード管理に AWS CodeCommit を使いました。
GitHub なら依存関係の更新は Dependabot に任せられますが、Dependabot は GitHub に統合された機能です。CodeCommit で同じ体験を作るには、別のツールを用意する必要があります。
そこで Renovate を CodeCommit 向けに実行し「更新 PR ができている」状態を作るところまでを試してみました。
作るもの
フロントエンドとバックエンドでリポジトリが分かれているプロジェクトを想定し、2 つのリポジトリを Renovate の対象にします。EventBridge Scheduler が定期的に CodeBuild を起動し、CodeBuild 上で Renovate を実行します。Renovate は各レジストリの最新バージョンを確認し、更新があればそれぞれのリポジトリにプルリクエストを作成します。
前提として、CodeCommit 上にフロントエンド用・バックエンド用の 2 リポジトリ（本記事では sample-frontend / sample-backend）がある状態から始めます。
ほかに必要なのは、CodeCommit / CodeBuild / EventBridge Scheduler / IAM を操作できる権限です。Renovate を動かすための Node.js は CodeBuild 側で用意するので、手元の環境には依存しません。
Renovate の起動は誰が担うのか
最初に押さえておきたいのは、Renovate 本体にはスケジューラや常駐の仕組みが無いことです。Renovate は 1 回起動すると「対象リポジトリを読む → 更新を計算する → PR を作る」を一巡して終了する CLI プログラムで、どこで動かしても PR は CodeCommit 上に作られます。
GitHub で Renovate を使う場合は Mend がホストする App が定期起動を肩代わりしてくれますが、セルフホストでは「いつ・どこで動かすか」を自分で用意します。
Renovate とは
Renovate は Mend.io が開発するオープンソースの依存関係更新ツールです。リポジトリ内の依存関係（公開・非公開の両方）への参照を探し、新しいバージョンがあれば自動で更新プルリクエストを作成します。90 を超えるパッケージマネージャーに対応しています。
Dependabot との一番大きな違いは、Renovate は「どこで動かすか」を選べることです。Mend のホスティングサービスを使うこともできれば、npm パッケージや Docker イメージとして自前の環境で回すこともできます。このセルフホスト実行ができるおかげで、CodeCommit のように Bot が用意されていないプラットフォームにも対応できます。
Renovate の 1 回の実行は、次の流れで進みます。
- オンボーディング — 設定ファイル（
renovate.json）が無ければ、それを追加する PR をまず作る - 抽出 —
package.jsonやDockerfileなどを解析し、依存関係の一覧を作る - 照会 — 各レジストリに問い合わせて最新バージョンを調べる
- ブランチ／PR 作成 — 更新があればブランチを切って PR を作る
CodeCommit サポート状況
Renovate は GitHub や GitLab などに加えて、セルフホスト実行のプラットフォームとして CodeCommit をサポートしています。ただし codecommit は gerrit や local と並ぶ experimental（実験的）なプラットフォームで、実験的機能はいつ変更・削除されてもおかしくないという扱いです。
そのうえで、メンテナの方針を正確に押さえておく必要があります。公式ドキュメントには、2024 年 7 月に Amazon が CodeCommit を非推奨化して以降フィーチャーフリーズ状態にあり、2025 年 11 月に Amazon がサポートを復活させたこともその状況を変えるものではない、として、企業が機能を提供し、かつそれを維持する意思を示さない限り、CodeCommit 向けの新機能は追加しないと明記されています。
つまり、GA 復帰によってサポートが広がることを前提にはせず、現在の機能範囲で運用を組み立てるのが現実的です。
CodeCommit 自体の提供状況
CodeCommit は 2024 年 7 月に新規利用の受付を停止していましたが、2025 年 11 月 24 日に全面的な一般提供（GA）へ復帰し、新規サインアップも同日から再開されました。
AWS は復帰の理由として、深い IAM 統合・VPC エンドポイント対応・CloudTrail ログ・CodePipeline / CodeBuild との連携といった特性が、規制産業や開発基盤を AWS 内に閉じたいチームにとって価値を持つ可能性があると述べています。
ロードマップとしては、Git LFS 対応（2026 年 Q1）と、eu-south-2・ca-west-1 へのリージョン拡大（2026 年 Q3 以降）が示されています。
対象リポジトリ
対象の 2 リポジトリには、それぞれ次の package.json が置いてあります。Renovate の動きを確認しやすいよう、あえて少し古いバージョンを指定しています。
sample-frontend:
{
"name": "sample-frontend",
"version": "1.0.0",
"private": true,
"dependencies": {
"axios": "0.27.2",
"react": "18.2.0",
"react-dom": "18.2.0"
}
}
sample-backend:
{
"name": "sample-backend",
"version": "1.0.0",
"private": true,
"dependencies": {
"express": "4.17.1"
},
"devDependencies": {
"typescript": "5.0.4"
}
}
Renovate を CodeBuild で動かす
buildspec を置く専用リポジトリ
公式ドキュメントでは、Renovate 実行用の buildspec を置く専用リポジトリを用意する構成が案内されています。対象リポジトリの中に実行基盤の設定が混ざらず、対象リポジトリが増えても buildspec は 1 箇所で済むためです。
今回もこの構成に従います。CodeCommit のコンソールで renovate-runner リポジトリを作成し、「ファイルの作成」からリポジトリ直下に renovate.yml という名前で次の buildspec をコミットします。
Available runtimes - AWS CodeBuild
version: 0.2
env:
shell: bash
variables:
RENOVATE_PLATFORM: "codecommit"
RENOVATE_REPOSITORIES: '["sample-frontend", "sample-backend"]'
LOG_LEVEL: "info"
AWS_REGION: "ap-northeast-1"
phases:
install:
runtime-versions:
nodejs: 24
commands:
- git config --global credential.helper '!aws codecommit credential-helper $@'
- git config --global credential.UseHttpPath true
build:
on-failure: CONTINUE
commands:
- npm install -g renovate
- export RENOVATE_CONFIG="{\"extends\":[\"config:recommended\"],\"customEnvVariables\":{\"AWS_CONTAINER_CREDENTIALS_RELATIVE_URI\":\"$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI\",\"AWS_REGION\":\"$AWS_REGION\"}}"
- renovate
必要な IAM ポリシー
Renovate が CodeCommit を操作するための IAM ポリシーは公式ドキュメントに記載があります。IAM のコンソールで以下のポリシーを renovate-codecommit-policy などの名前で作成しておきます。Resource の値は対象としたいリソースに合わせて変更してください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RenovatePolicy",
"Effect": "Allow",
"Action": [
"codecommit:DeleteCommentContent",
"codecommit:UpdatePullRequestDescription",
"codecommit:GitPull",
"codecommit:ListPullRequests",
"codecommit:GetCommentsForPullRequest",
"codecommit:ListRepositories",
"codecommit:UpdatePullRequestTitle",
"codecommit:GetFile",
"codecommit:UpdateComment",
"codecommit:GetRepository",
"codecommit:CreatePullRequest",
"codecommit:CreatePullRequestApprovalRule",
"codecommit:GitPush",
"codecommit:UpdatePullRequestStatus",
"codecommit:GetPullRequest"
],
"Resource": "*"
}
]
}
CodeBuild プロジェクトの作成
CodeBuild のコンソールで「ビルドプロジェクトを作成」し、次の値を設定します。
- プロジェクト名:
renovate - ソースプロバイダ: AWS CodeCommit、リポジトリ:
renovate-runner、ブランチ:main - 環境イメージ:
aws/codebuild/amazonlinux-x86_64-standard:6.0（マネージド型） - サービスロール: 新しいサービスロール（自動作成に任せます）
- Buildspec: 「buildspec ファイルを使用する」を選び、ファイル名に
renovate.ymlを指定 - アーティファクト: なし
作成後、IAM のコンソールで自動作成されたサービスロールに、先ほどの renovate-codecommit-policy をアタッチします。自動作成されたロールには CodeBuildBasePolicy-renovate-ap-northeast-1 というポリシーが付いていますが、
その内容は CloudWatch Logs への出力、ソースリポジトリ（renovate-runner）の GitPull、テストレポートやアーティファクト用の権限といった、ビルド自体を動かすためのものに限られています。
Renovate が対象リポジトリに PR を作るための権限は含まれていないため、追加でアタッチする必要があります。
動作を確認する
ここまでの設定が正しく機能するか、実際にビルドを実行して確認します。
オンボーディング PR の作成
CodeBuild のコンソールから「ビルドを開始」を選択し、手動でビルドを実行します。
初回実行時は、Renovate が対象リポジトリの状態を解析し、設定ファイル renovate.json を追加するためのオンボーディング PR（Configure Renovate）を作成します。今回は 2 リポジトリを対象にしているため、それぞれに PR が作成されるはずです。
ビルドが正常に完了したら、各リポジトリの PR を確認します。
フロントエンド
バックエンド
フロントエンド・バックエンドの両方のリポジトリで、オンボーディング PR が作成されていることを確認できました。
依存関係の更新 PR の作成
PR の内容を確認したうえで両方マージし、再度ビルドを実行します。renovate.json が取り込まれた状態になるため、今度は依存関係の更新 PR が作成されます。
事前に古いバージョンで登録しておいた axios や express などの更新 PR が作成されていれば成功です。
フロントエンド
バックエンド
想定どおり、フロントエンドとバックエンドの両方で依存関係を更新する PR が作成されました。これで、1 つの CodeBuild プロジェクトから複数リポジトリの依存関係を Renovate で管理できることを確認できました。
実運用に向けて
今回は手動での CodeBuild 実行と、config:recommended のまま動かしました。実際の運用では、定期スケジュールを組む、PR 数の制御や更新対象の絞り込みといった Renovate 側の設定を、もう一段詰めていくことになります。
プリセットの選び方や prConcurrentLimit、グルーピングなどの設定は、別記事にまとめる予定です。
まとめ
CodeCommit を利用している環境でも、Renovate をセルフホスト実行することで、Dependabot のように依存関係更新のプルリクエストを自動作成できました。次回は CodeBuild と EventBridge Scheduler を組み合わせて定期実行を組んでみます！
automerge や Dependency Dashboard はサポート対象外、今後の機能追加も限定的といった制約はあります。それでも「依存関係の更新を定期的なレビューの習慣に乗せる仕組み」としては十分に機能します。CodeCommit が GA に復帰したこともあり、CodeCommit を使い続ける選択をしたチームの参考になれば幸いです。
参考
