CI/CD設定構文 横断比較
GitHub Actions・GitLab CI・CircleCI・AWS CodeBuildの構文を「やりたいこと」で逆引き比較
カテゴリ
重要度
表示するサービス
28 件のパターン
コードをpushしたときに自動でパイプラインを実行する
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "push"
# または特定ブランチのみ
only:
- main
- developworkflows:
build:
jobs:
- test:
filters:
branches:
only:
- main
- develop# CodePipeline側でトリガーを設定
# buildspec.yml はビルド設定のみ記述
version: 0.2
phases:
build:
commands:
- echo "Build started"⚠ 注意:CodeBuild単体ではなくCodePipelineでトリガー設定を行う
公式ドキュメントプルリクエスト(MR)の作成・更新時にパイプラインを実行する
on:
pull_request:
branches:
- main
types:
- opened
- synchronize
- reopenedworkflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
# ジョブレベルでの指定
job-name:
only:
- merge_requests⚠ 注意:GitLabはMerge Request(MR)と呼ぶ
公式ドキュメントworkflows:
build:
jobs:
- test:
filters:
branches:
ignore: main⚠ 注意:CircleCIはPR専用トリガーはない。GitHub側のブランチ保護で代替
公式ドキュメント# GitHub連携の場合はCodePipelineで設定
# WebhookをPRイベントに限定
FilterGroups:
- - Type: EVENT
Pattern: PULL_REQUEST_CREATED,PULL_REQUEST_UPDATEDスケジュール(cron式)で定期的にパイプラインを実行する
on:
schedule:
# 毎日 JST 9:00 (UTC 0:00)
- cron: '0 0 * * *'⚠ 注意:タイムゾーンはUTC固定。JSTは-9時間で計算する
公式ドキュメント# UIから設定: Settings → CI/CD → Schedules
# または .gitlab-ci.yml で変数を使って条件分岐
job-name:
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"# .circleci/config.yml に追加
schedules:
nightly:
cron: "0 0 * * *"
filters:
branches:
only:
- main⚠ 注意:CircleCI v2.1以降で利用可能
公式ドキュメント# EventBridge (CloudWatch Events) でスケジュール設定 # rate形式 rate(1 day) # cron形式(UTC) cron(0 0 * * ? *)
手動でパイプラインを実行できるようにする(UIからの起動)
on:
workflow_dispatch:
inputs:
environment:
description: 'デプロイ環境'
required: true
default: 'staging'
type: choice
options:
- staging
- production# UIの「Run pipeline」ボタンで手動実行可能
# 変数を渡す場合
variables:
DEPLOY_ENV:
value: "staging"
description: "デプロイ環境"# CircleCI UIから「Trigger Pipeline」で手動実行
# パラメーターを渡す場合
parameters:
deploy-env:
type: string
default: "staging"# AWS CLIで手動実行 aws codebuild start-build --project-name my-project --environment-variables-override name=DEPLOY_ENV,value=staging,type=PLAINTEXT
タグをpushしたときにリリースパイプラインを実行する
workflows:
release:
jobs:
- deploy:
filters:
tags:
only: /^v.*/
branches:
ignore: /.*/⚠ 注意:CircleCIはタグトリガー時にbranchesのignoreも明示する必要がある
公式ドキュメント# Webhookフィルターでタグpushに限定
FilterGroups:
- - Type: EVENT
Pattern: PUSH
- Type: HEAD_REF
Pattern: ^refs/tags/v.*基本的なジョブを定義してコマンドを実行する
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm testjobs:
build:
docker:
- image: cimg/node:20.0
steps:
- checkout
- run:
name: Install dependencies
command: npm ci
- run:
name: Run tests
command: npm testversion: 0.2
phases:
install:
runtime-versions:
nodejs: 20
pre_build:
commands:
- npm ci
build:
commands:
- npm test複数のジョブを並列で実行してビルド時間を短縮する
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm run lint
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test
type-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm run type-check⚠ 注意:依存関係を指定しなければ全ジョブが並列実行される
公式ドキュメントstages: - check lint: stage: check script: npm run lint test: stage: check script: npm test type-check: stage: check script: npm run type-check
⚠ 注意:同じstageに属するジョブは並列実行される
公式ドキュメントworkflows:
build:
jobs:
- lint
- test
- type-check⚠ 注意:依存関係(requires)を指定しなければ並列実行
公式ドキュメント# CodePipeline でステージ内に複数のActionを並列配置 # buildspec.yml の build フェーズは並列実行不可 # 並列化はCodePipeline側のAction設定で行う
⚠ 注意:buildspec.yml単体での並列化は限定的。CodePipelineで複数Actionを並列配置する
公式ドキュメントジョブに依存関係を設定してテスト後にデプロイを実行する
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test
deploy:
needs: test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm run deploystages: - test - deploy test: stage: test script: npm test deploy: stage: deploy script: npm run deploy needs: [test]
⚠ 注意:needsを使うとステージ順序を待たず依存ジョブ完了次第開始できる
公式ドキュメントworkflows:
build-deploy:
jobs:
- test
- deploy:
requires:
- test# CodePipeline でステージを順番に定義 # Stage1: Test → Stage2: Deploy # 前のステージが成功しないと次に進まない
ジョブのタイムアウト時間を設定して無限待機を防ぐ
jobs:
build:
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: actions/checkout@v4
- run: npm test⚠ 注意:デフォルトは360分(6時間)。意図しない長時間実行でクレジットを消費しないよう設定推奨
公式ドキュメントjob-name: script: npm test timeout: 30 minutes # または # timeout: 1h 30m
jobs:
build:
docker:
- image: cimg/node:20.0
steps:
- run:
name: Run tests
command: npm test
no_output_timeout: 30m⚠ 注意:no_output_timeoutは出力がない場合のタイムアウト。全体のタイムアウトはUIで設定
公式ドキュメントversion: 0.2 # buildspec.yml ではなくプロジェクト設定でタイムアウトを指定 # AWS CLI: # aws codebuild update-project # --name my-project # --timeout-in-minutes 30
⚠ 注意:タイムアウトはプロジェクト設定で指定(5〜480分)
公式ドキュメントNode.jsのnode_modulesをキャッシュしてnpm installを高速化する
- uses: actions/cache@v4
with:
path: ~/.npm
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-
- run: npm ci⚠ 注意:hashFilesのパスはワークスペースルート基準。node_modulesよりも~/.npmをキャッシュするのが推奨
公式ドキュメントjob-name:
cache:
key:
files:
- package-lock.json
paths:
- node_modules/
policy: pull-push
script:
- npm cisteps:
- restore_cache:
keys:
- v1-deps-{{ checksum "package-lock.json" }}
- v1-deps-
- run: npm ci
- save_cache:
key: v1-deps-{{ checksum "package-lock.json" }}
paths:
- node_modules⚠ 注意:save_cacheは同じキーでは上書きされない。キーを変更したい場合は v1- のプレフィックスを更新する
公式ドキュメントversion: 0.2
cache:
paths:
- 'node_modules/**/*'
phases:
install:
commands:
- npm ci⚠ 注意:S3キャッシュが必要な場合はプロジェクト設定でS3バケットを指定する
公式ドキュメントPythonのpipパッケージをキャッシュしてインストールを高速化する
- uses: actions/setup-python@v5
with:
python-version: '3.12'
cache: 'pip'
- run: pip install -r requirements.txt⚠ 注意:setup-python の cache オプションで自動キャッシュ。pip / pipenv / poetry に対応
公式ドキュメントjob-name:
image: python:3.12
cache:
paths:
- .cache/pip
variables:
PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
script:
- pip install -r requirements.txtsteps:
- restore_cache:
keys:
- pip-{{ checksum "requirements.txt" }}
- run: pip install -r requirements.txt
- save_cache:
key: pip-{{ checksum "requirements.txt" }}
paths:
- ~/.cache/pipversion: 0.2
cache:
paths:
- '/root/.cache/pip/**/*'
phases:
install:
runtime-versions:
python: 3.12
commands:
- pip install -r requirements.txtDockerイメージのレイヤーをキャッシュしてビルド時間を短縮する
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Build and push
uses: docker/build-push-action@v5
with:
cache-from: type=gha
cache-to: type=gha,mode=max
push: true
tags: myapp:latest⚠ 注意:GitHub Actions Cache backend(type=gha)を使うとキャッシュが自動管理される
公式ドキュメントbuild:
image: docker:24
services:
- docker:24-dind
variables:
DOCKER_BUILDKIT: 1
script:
- docker buildx build
--cache-from type=registry,ref=$CI_REGISTRY_IMAGE:cache
--cache-to type=registry,ref=$CI_REGISTRY_IMAGE:cache,mode=max
--push
-t $CI_REGISTRY_IMAGE:latest .- restore_cache:
keys:
- docker-{{ .Branch }}-{{ checksum "Dockerfile" }}
- run: docker build -t myapp .
- save_cache:
key: docker-{{ .Branch }}-{{ checksum "Dockerfile" }}
paths:
- /tmp/docker-cache⚠ 注意:Docker Layer Caching(DLC)はCircleCI有料プランの機能
公式ドキュメント# プロジェクト設定でDockerレイヤーキャッシュを有効化
# buildspec.yml:
version: 0.2
phases:
pre_build:
commands:
- aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REGISTRY
build:
commands:
- docker buildx build --cache-from $ECR_REGISTRY/myapp:cache -t myapp .⚠ 注意:CodeBuild のDocker Layer Cachingは追加料金なしで利用可能(設定で有効化)
公式ドキュメント環境変数を定義してビルド・テストで参照する
env:
NODE_ENV: production
API_VERSION: v2
jobs:
build:
runs-on: ubuntu-latest
env:
BUILD_MODE: release # ジョブレベルの変数
steps:
- run: echo "Node env is $NODE_ENV"variables:
NODE_ENV: production
API_VERSION: v2
job-name:
variables:
BUILD_MODE: release # ジョブレベルの変数
script:
- echo "Node env is $NODE_ENV"jobs:
build:
docker:
- image: cimg/node:20.0
environment:
NODE_ENV: production
API_VERSION: v2
steps:
- run: echo "Node env is $NODE_ENV"version: 0.2
env:
variables:
NODE_ENV: production
API_VERSION: v2
phases:
build:
commands:
- echo "Node env is $NODE_ENV"APIキーやパスワードなどのシークレットを安全に参照する
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy
env:
API_KEY: ${{ secrets.API_KEY }}
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
run: ./deploy.sh⚠ 注意:Secretsはリポジトリ設定 → Secrets and variables から登録。ログに出力されてもマスクされる
公式ドキュメント# UIで設定: Settings → CI/CD → Variables → Add variable (Masked: ON)
deploy:
script:
- echo "Deploying with key $API_KEY"
- ./deploy.sh
# シークレット変数は自動で参照可能(定義不要)⚠ 注意:Maskedにするとログ出力されない。Protectedにすると保護ブランチのみ参照可能
公式ドキュメント# Project Settings → Environment Variables に登録
# buildspec.yml では $変数名 で参照
jobs:
deploy:
docker:
- image: cimg/base:stable
steps:
- run: echo "API_KEY=$API_KEY" >> .envversion: 0.2
env:
secrets-manager:
API_KEY: arn:aws:secretsmanager:ap-northeast-1:123456789:secret:my-secret:API_KEY
parameter-store:
DB_PASSWORD: /myapp/db-password
phases:
build:
commands:
- echo "Deploying with $API_KEY"⚠ 注意:Secrets ManagerまたはParameter Store(SecureString)との統合が推奨
公式ドキュメントstaging / production などデプロイ環境ごとに変数を切り替える
jobs:
deploy-staging:
environment: staging
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh
env:
API_URL: ${{ vars.API_URL }} # 環境変数(非シークレット)
API_KEY: ${{ secrets.API_KEY }} # 環境シークレット
deploy-production:
environment: production
needs: deploy-staging
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh
env:
API_URL: ${{ vars.API_URL }}
API_KEY: ${{ secrets.API_KEY }}⚠ 注意:Environmentsを使うと環境ごとにSecretsを分離できる。productionには承認ゲートも設定可能
公式ドキュメントdeploy-staging:
script: ./deploy.sh
environment:
name: staging
variables:
API_URL: https://staging.example.com
deploy-production:
script: ./deploy.sh
environment:
name: production
variables:
API_URL: https://example.com
when: manual# Contextsを使って環境ごとに変数を分離
workflows:
deploy:
jobs:
- deploy-staging:
context: staging-context
- deploy-production:
context: production-context
requires:
- deploy-staging# Parameter Storeで環境ごとにパスを分ける
# /staging/api-url → https://staging.example.com
# /production/api-url → https://example.com
version: 0.2
env:
parameter-store:
API_URL: /${DEPLOY_ENV}/api-urlAWS S3にビルド成果物をデプロイしてCloudFrontのキャッシュを削除する
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ap-northeast-1
- name: Deploy to S3
run: aws s3 sync ./dist s3://my-bucket --delete
- name: Invalidate CloudFront
run: |
aws cloudfront create-invalidation --distribution-id ${{ secrets.CF_DISTRIBUTION_ID }} --paths "/*"deploy:
image: amazon/aws-cli
script:
- aws s3 sync ./dist s3://$S3_BUCKET --delete
- aws cloudfront create-invalidation
--distribution-id $CF_DISTRIBUTION_ID
--paths "/*"
variables:
AWS_DEFAULT_REGION: ap-northeast-1⚠ 注意:AWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYはCI/CD変数に登録しておく
公式ドキュメント- run:
name: Deploy to S3
command: |
aws s3 sync ./dist s3://$S3_BUCKET --delete
aws cloudfront create-invalidation --distribution-id $CF_DISTRIBUTION_ID --paths "/*"version: 0.2
phases:
build:
commands:
- npm run build
post_build:
commands:
- aws s3 sync ./dist s3://$S3_BUCKET --delete
- aws cloudfront create-invalidation
--distribution-id $CF_DISTRIBUTION_ID
--paths "/*"⚠ 注意:CodeBuildのサービスロールにS3とCloudFrontの権限を付与する
公式ドキュメントNext.js / フロントエンドプロジェクトをVercelにデプロイする
- name: Deploy to Vercel
uses: amondnet/vercel-action@v25
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
vercel-org-id: ${{ secrets.ORG_ID }}
vercel-project-id: ${{ secrets.PROJECT_ID }}
vercel-args: '--prod' # 本番デプロイ(省略するとプレビュー)⚠ 注意:GitHubリポジトリをVercelに接続すると自動デプロイも設定可能
公式ドキュメントdeploy:
image: node:20
script:
- npm i -g vercel
- vercel --token $VERCEL_TOKEN --prod- run:
name: Deploy to Vercel
command: |
npm i -g vercel
vercel --token $VERCEL_TOKEN --prodversion: 0.2
phases:
install:
commands:
- npm install -g vercel
build:
commands:
- npm run build
post_build:
commands:
- vercel --token $VERCEL_TOKEN --prod⚠ 注意:VercelトークンはParameter StoreまたはSecrets Managerに保存する
公式ドキュメントDockerイメージをビルドしてDocker Hubにpushする
- uses: docker/login-action@v3
with:
username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }}
- uses: docker/build-push-action@v5
with:
push: true
tags: |
myuser/myapp:latest
myuser/myapp:${{ github.sha }}build-push:
image: docker:24
services:
- docker:24-dind
script:
- docker login -u $DOCKERHUB_USER -p $DOCKERHUB_TOKEN
- docker build -t $DOCKERHUB_USER/myapp:$CI_COMMIT_SHA .
- docker tag $DOCKERHUB_USER/myapp:$CI_COMMIT_SHA $DOCKERHUB_USER/myapp:latest
- docker push $DOCKERHUB_USER/myapp:$CI_COMMIT_SHA
- docker push $DOCKERHUB_USER/myapp:latest- run:
name: Build and push Docker image
command: |
echo "$DOCKERHUB_TOKEN" | docker login -u "$DOCKERHUB_USER" --password-stdin
docker build -t $DOCKERHUB_USER/myapp:$CIRCLE_SHA1 .
docker push $DOCKERHUB_USER/myapp:$CIRCLE_SHA1version: 0.2
phases:
pre_build:
commands:
- echo "$DOCKERHUB_TOKEN" | docker login -u "$DOCKERHUB_USER" --password-stdin
build:
commands:
- docker build -t $DOCKERHUB_USER/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION .
post_build:
commands:
- docker push $DOCKERHUB_USER/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION
- docker tag $DOCKERHUB_USER/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION $DOCKERHUB_USER/myapp:latest
- docker push $DOCKERHUB_USER/myapp:latestDockerイメージをAmazon ECRにpushしてECS/EKSで利用する
- uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: ap-northeast-1
- id: login-ecr
uses: aws-actions/amazon-ecr-login@v2
- uses: docker/build-push-action@v5
with:
push: true
tags: ${{ steps.login-ecr.outputs.registry }}/myapp:${{ github.sha }}build-ecr:
image: amazon/aws-cli
services:
- docker:24-dind
script:
- aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_REGISTRY
- docker build -t $ECR_REGISTRY/myapp:$CI_COMMIT_SHA .
- docker push $ECR_REGISTRY/myapp:$CI_COMMIT_SHA- run:
name: Push to ECR
command: |
aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin $ECR_REGISTRY
docker build -t $ECR_REGISTRY/myapp:$CIRCLE_SHA1 .
docker push $ECR_REGISTRY/myapp:$CIRCLE_SHA1version: 0.2
phases:
pre_build:
commands:
- aws ecr get-login-password --region $AWS_DEFAULT_REGION |
docker login --username AWS --password-stdin $ECR_REGISTRY
build:
commands:
- docker build -t $ECR_REGISTRY/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION .
post_build:
commands:
- docker push $ECR_REGISTRY/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION
- printf '[{"name":"myapp","imageUri":"%s"}]' $ECR_REGISTRY/myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION > imagedefinitions.json
artifacts:
files: imagedefinitions.json⚠ 注意:imagedefinitions.jsonをアーティファクトとして出力するとCodeDeployでECSデプロイに使える
公式ドキュメントDockerfileからイメージをビルドしてタグを付ける
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v3
- name: Build Docker image
uses: docker/build-push-action@v5
with:
context: .
push: false
tags: myapp:${{ github.sha }}
load: truebuild:
image: docker:24
services:
- docker:24-dind
variables:
DOCKER_BUILDKIT: 1
script:
- docker build -t myapp:$CI_COMMIT_SHA .jobs:
build:
machine:
image: ubuntu-2204:current
steps:
- checkout
- run: docker build -t myapp:$CIRCLE_SHA1 .⚠ 注意:machine executorを使うとDocker-in-Dockerが不要
公式ドキュメントversion: 0.2
phases:
build:
commands:
- docker build -t myapp:$CODEBUILD_RESOLVED_SOURCE_VERSION .⚠ 注意:プロジェクト設定でPrivilegedモードを有効にする必要がある
公式ドキュメントdocker-composeでDBなどの依存サービスを起動してE2Eテストを実行する
services:
postgres:
image: postgres:16
env:
POSTGRES_PASSWORD: postgres
options: >-
--health-cmd pg_isready
--health-interval 10s
--health-timeout 5s
--health-retries 5
ports:
- 5432:5432
steps:
- run: npm run test:e2e
env:
DATABASE_URL: postgres://postgres:postgres@localhost:5432/testtest-e2e:
image: node:20
services:
- name: postgres:16
alias: postgres
variables:
POSTGRES_PASSWORD: postgres
DATABASE_URL: postgres://postgres:postgres@postgres:5432/test
script:
- npm run test:e2ejobs:
test-e2e:
docker:
- image: cimg/node:20.0
- image: postgres:16
environment:
POSTGRES_PASSWORD: postgres
environment:
DATABASE_URL: postgres://postgres:postgres@localhost:5432/test
steps:
- checkout
- run: npm run test:e2eversion: 0.2
phases:
pre_build:
commands:
- docker-compose up -d db
- sleep 10 # DB起動待機
build:
commands:
- DATABASE_URL=postgres://postgres:postgres@localhost:5432/test npm run test:e2e
post_build:
commands:
- docker-compose down⚠ 注意:Privilegedモードの有効化が必要
公式ドキュメント複数のNode.jsバージョンで並列テストして互換性を確認する
jobs:
test:
strategy:
matrix:
node-version: [18, 20, 22]
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
- run: npm ci && npm testtest:
image: node:$NODE_VERSION
parallel:
matrix:
- NODE_VERSION: ['18', '20', '22']
script:
- npm ci
- npm test# CircleCIにはネイティブのmatrixはない
# parameters で代替
parameters:
node-version:
type: string
default: "20"
jobs:
test:
docker:
- image: cimg/node:<< pipeline.parameters.node-version >>
steps:
- checkout
- run: npm ci && npm test⚠ 注意:CircleCIでの複数バージョンテストはmatrix strategyがなくworkflow + parametersで代替
公式ドキュメント# CodeBuildにはmatrixビルドがない # 複数プロジェクトを並列実行する方法か # Lambda + Step Functionsで制御する方法がある
⚠ 注意:Batch Buildを使えば複数設定を並列実行できるが、完全なmatrix strategyは非対応
公式ドキュメントWindows / macOS / Linux の複数OSで並列テストしてクロスプラットフォーム互換性を確認する
jobs:
test:
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macos-latest]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@v4
- run: npm ci && npm test# GitLab SaaSのShared Runnerは主にLinux
# macOS/Windowsは有料またはセルフホストRunnerが必要
test-linux:
image: node:20
script: npm ci && npm test
test-windows:
tags:
- windows
script:
- npm ci
- npm test⚠ 注意:macOS/Windowsランナーは追加設定が必要
公式ドキュメントjobs:
test-linux:
docker:
- image: cimg/node:20.0
steps:
- checkout
- run: npm ci && npm test
test-macos:
macos:
xcode: "15.0"
steps:
- checkout
- run: node --version && npm ci && npm test⚠ 注意:macOSはCircleCI有料プランの機能
公式ドキュメント# CodeBuildはLinux / Windows / macOS に対応 # 環境ごとに別プロジェクトを作成して並列実行 # 環境の指定(CloudFormation): # Environment: # Type: LINUX_CONTAINER / WINDOWS_SERVER_2019_CONTAINER / MAC_ARM
ブランチ名によってジョブの実行・スキップを切り替える
jobs:
deploy:
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- run: echo "Deploying to production"
preview:
if: startsWith(github.ref, 'refs/heads/feature/')
runs-on: ubuntu-latest
steps:
- run: echo "Deploying preview"deploy-prod:
script: ./deploy.sh production
rules:
- if: $CI_COMMIT_BRANCH == "main"
deploy-preview:
script: ./deploy.sh preview
rules:
- if: $CI_COMMIT_BRANCH =~ /^feature//workflows:
build-deploy:
jobs:
- deploy-prod:
filters:
branches:
only: main
- deploy-preview:
filters:
branches:
only: /^feature/.*/version: 0.2
phases:
build:
commands:
- |
if [ "$CODEBUILD_WEBHOOK_BASE_REF" = "refs/heads/main" ]; then
./deploy.sh production
else
./deploy.sh preview
fi⚠ 注意:CODEBUILD_WEBHOOK_BASE_REFはWebhookトリガー時のみ設定される
公式ドキュメント本番デプロイ前に手動承認ゲートを設けて意図しないデプロイを防ぐ
jobs:
deploy-production:
environment: production # Environmentに承認ルールを設定
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh production⚠ 注意:リポジトリ設定のEnvironmentsで「Required reviewers」を追加するとUIで承認が必要になる
公式ドキュメントdeploy-production: script: ./deploy.sh production when: manual # UIで「▶ Run」ボタンを押すまで実行されない environment: production
workflows:
deploy:
jobs:
- hold:
type: approval # UIで承認するまでブロック
- deploy-production:
requires:
- hold# CodePipelineのManual Approvalアクションで実現 # ステージ間にApprovalアクションを挿入 # SNS通知でメール/Slackに承認依頼を送信できる
ビルド・テストが失敗したときだけクリーンアップ処理やアラートを実行する
steps:
- run: npm test
- name: Cleanup on failure
if: failure()
run: |
echo "Build failed! Cleaning up..."
./cleanup.sh⚠ 注意:failure() / success() / always() / cancelled() が使用可能
公式ドキュメントtest:
script: npm test
after_script:
- |
if [ "$CI_JOB_STATUS" = "failed" ]; then
echo "Job failed! Cleaning up..."
./cleanup.sh
fisteps:
- run: npm test
- run:
name: Cleanup on failure
command: |
echo "Cleaning up..."
./cleanup.sh
when: on_fail⚠ 注意:when: on_fail / on_success / always が使用可能
公式ドキュメントversion: 0.2
phases:
build:
commands:
- npm test
post_build:
commands:
- |
if [ "$CODEBUILD_BUILD_SUCCEEDING" = "0" ]; then
echo "Build failed! Cleaning up..."
./cleanup.sh
fi⚠ 注意:CODEBUILD_BUILD_SUCCEEDING: 成功=1, 失敗=0
公式ドキュメントビルド結果(成功・失敗)をSlackに通知する
- name: Notify Slack uses: slackapi/[email protected] if: always() with: payload: | { "text": "Build ${{ job.status }}: ${{ github.workflow }} on ${{ github.repository }}", "attachments": [{ "color": "${{ job.status == 'success' && 'good' || 'danger' }}", "fields": [{"title": "Branch", "value": "${{ github.ref_name }}", "short": true}] }] } env: SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK
notify-slack:
image: curlimages/curl
script:
- |
STATUS="成功 ✅"
COLOR="good"
if [ "$CI_JOB_STATUS" != "success" ]; then
STATUS="失敗 ❌"
COLOR="danger"
fi
curl -X POST $SLACK_WEBHOOK_URL -H 'Content-type: application/json' --data "{"text":"ビルド${STATUS}: ${CI_PROJECT_NAME} (${CI_COMMIT_BRANCH})"}"
when: always- slack/notify:
event: always
custom: |
{
"text": "Build $CIRCLE_JOB",
"attachments": [{
"color": "{{ #if failed }}danger{{ else }}good{{ /if }}",
"text": "$CIRCLE_PROJECT_REPONAME ($CIRCLE_BRANCH)"
}]
}⚠ 注意:circleci/slack Orbを使う。config.yml に orbs: slack: circleci/[email protected] を追加
公式ドキュメント# CodeBuildのBuild Notificationを使う
# または SNS → Lambda → Slack Webhook
# buildspec.yml に直接書く場合:
version: 0.2
phases:
post_build:
commands:
- |
STATUS="${CODEBUILD_BUILD_SUCCEEDING:-0}"
if [ "$STATUS" = "1" ]; then
MSG="✅ ビルド成功"
else
MSG="❌ ビルド失敗"
fi
curl -X POST $SLACK_WEBHOOK_URL -H 'Content-type: application/json' --data "{"text":"${MSG}: $CODEBUILD_BUILD_ID"}"ビルドが失敗したときだけSlack / メールで通知する
- name: Notify Slack on failure uses: slackapi/[email protected] if: failure() with: payload: | {"text": "❌ ビルド失敗: ${{ github.workflow }} (${{ github.ref_name }})\n${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}"} env: SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK
notify-failure:
image: curlimages/curl
script:
- |
curl -X POST $SLACK_WEBHOOK_URL --data "{"text":"❌ ビルド失敗: $CI_PROJECT_NAME ($CI_COMMIT_BRANCH)"}"
rules:
- if: $CI_PIPELINE_SOURCE
when: on_failure- slack/notify:
event: fail
mentions: '@oncall'
custom: |
{"text": "❌ ビルド失敗: $CIRCLE_PROJECT_REPONAME ($CIRCLE_BRANCH)"}# AWS Developer Toolsの通知ルールを使う
# ビルド失敗イベント → SNS → メール / Slack (Chatbot)
# または buildspec.yml 内で条件判定
version: 0.2
phases:
post_build:
commands:
- |
if [ "${CODEBUILD_BUILD_SUCCEEDING}" = "0" ]; then
aws sns publish --topic-arn $SNS_TOPIC_ARN --message "Build failed: $CODEBUILD_BUILD_ID"
fiよくある質問
どのCI/CDサービスに対応していますか?
GitHub Actions・GitLab CI・CircleCI・AWS CodeBuild(+ CodePipeline)の4サービスに対応しています。各サービスの設定ファイルや構文の違いを横断的に比較できます。
「キャッシュ」「デプロイ」など目的から逆引き検索できますか?
はい。検索ボックスにやりたいこと(例:「キャッシュ」「S3」「承認」「Slack」)を入力すると、目的・タグ・コードスニペット内を横断検索します。
GitHub ActionsからGitLab CIに移行したい場合に使えますか?
はい、それがこのツールのメインユースケースの一つです。「push時に実行」「依存関係のキャッシュ」「デプロイ」など各目的で4サービスのコードを並べて比較できるため、移行時の対応表として活用できます。
スニペットはコピーしてそのまま使えますか?
テンプレートとして活用いただけますが、プロジェクト名・シークレット名・リポジトリ設定など環境固有の値は各自で書き換えてください。また、ライブラリのバージョンは最新の公式ドキュメントで確認することをおすすめします。
AWS CodeBuildとAWS CodePipelineの違いは?
CodeBuildはビルド・テスト処理を実行するサービスで、buildspec.ymlで設定します。CodePipelineはCI/CDのパイプライン全体(ソース取得→ビルド→デプロイ)を管理するオーケストレーターです。トリガー設定や承認ゲートはCodePipeline側で行います。
データはどのくらいの頻度で更新されますか?
各CI/CDサービスのメジャーな仕様変更や新機能追加に合わせて定期的に更新しています。公式の最新情報は各スニペットの「公式ドキュメント」リンクからご確認ください。
「注意点」はどういう情報が書いてありますか?
サービス固有の落とし穴(例:GitHub ActionsのhashFilesのパス基準、CircleCIのsave_cacheの上書き不可仕様)、有料プランのみの機能、追加設定が必要な項目などを記載しています。
掲載されていない設定パターンについて要望できますか?
ぱんだツールズのX(旧Twitter)アカウントへご連絡ください。定期更新時に追加を検討します。
開発者ツール一覧
すべて見るこのツールについて
使い方
- 検索ボックスにやりたいこと(例:「キャッシュ」「Slackに通知」「本番デプロイ 承認」)を入力
- カテゴリボタンで「トリガー・起動条件」「キャッシュ・高速化」「デプロイ」等に絞り込む
- 「重要度」フィルターで「必須」を選ぶと特に頻出の設定パターンに絞れる
- 「表示するサービス」で移行先・移行元のCI/CDサービスだけを表示して比較する
- スニペットの「コピー」ボタンでコードを取得し、プロジェクトに合わせて修正する
このツールの特徴
- ✓「やりたいこと」起点の逆引き検索:公式ドキュメントはサービス単位の仕様書だが、このツールは「キャッシュしたい」「Slackに通知したい」という目的から探せる
- ✓4サービス横断比較:GitHub Actions・GitLab CI・CircleCI・AWS CodeBuildの同等設定を並べて比較。移行案件の「対応表」として使える
- ✓落とし穴・注意点を明記:「CircleCIのsave_cacheは同じキーで上書きされない」「GitHub ActionsのhashFilesはワークスペースルート基準」など、ハマりがちなポイントを記載
- ✓日本語ファースト:目的・カテゴリ・注意事項がすべて日本語。英語ドキュメントを読む前のファーストステップとして使える
- ✓公式ドキュメントへの直リンク:スニペットごとに公式ドキュメントリンクを掲載。確認・深掘りがすぐにできる
こんなときに便利
- •GitHub ActionsからGitLab CI(またはその逆)に移行するときの構文対応表として
- •転職・異動で初めて触るCI/CDサービスの設定を素早くキャッチアップしたい
- •「cronどう書くんだっけ」「マトリクスビルドの構文は?」をすぐに確認したい
- •チームで複数CI/CDを使っていて、設定の統一・標準化を進めたい
- •レビューやペアプロで「他サービスではこう書く」を即確認したい
4サービスの位置づけと選定ポイント
- GHGitHub Actions:GitHubリポジトリと完全統合。無料枠が充実しており、OSSや個人開発に最適。Marketplaceのアクションエコシステムが最大の強み。
- GLGitLab CI:GitLabとの完全統合。セルフホスト(GitLab CE/EE)での柔軟な運用が可能。ステージ制の分かりやすいパイプライン設計が特徴。
- CCCircleCI:独立したCI/CDサービスとしての老舗。Orbsというエコシステムや、macOS/Linux実行環境の豊富な選択肢が強み。
- AWSAWS CodeBuild + CodePipeline:AWSサービスとの深い統合(ECR・ECS・S3・Lambda等)が最大の強み。IAMロールでの権限管理が自然に組み込める。
仕組み・技術的背景
すべてのデータ(設定パターン・コードスニペット・解説)はブラウザ内に埋め込まれており、 検索・フィルタリングも完全にクライアントサイドで完結します。外部APIへのリクエストは発生しません。 データはTypeScriptのオブジェクトとして管理されており、定期的な保守更新が可能な構造になっています。 YAMLのシンタックスハイライトはCSSのみで実装しており、重いライブラリは使用していません。
注意事項・制限事項
- ⚠スニペットはテンプレートです。プロジェクト名・シークレット名・AWSリソースIDなど環境固有の値は必ず書き換えてください
- ⚠アクションのバージョン(例:actions/cache@v4)は最新バージョンを確認してから使用してください
- ⚠各CI/CDサービスの仕様は頻繁に更新されます。実際の設定前に公式ドキュメントを必ず確認してください