ビルドにバージョン情報を含める

ソフトウェアを利用するユーザーは、自分が使用しているバージョンを把握する必要があります。Coroidは各リリースにバージョンとビルド番号を付与し、それらをビルド用パイプラインに渡した後、デプロイしたリリースが実行環境で正しく動作しているかを検証します。

このページの設定内容はすべて、プロジェクトごとに「リリース → リリース設定 → バージョニング。

バージョンの取得元#

プロジェクトごとに以下のいずれかのソースを選択します：

• Coroidが自動的に割り当てます（デフォルト）：リリース準備時にCoroidが次のバージョンを提案します。これは、プロジェクトで過去にリリースされた最も高いバージョンの末尾番号をインクリメントする仕組みです。1.4.0は1.4.1に続き、最初のリリースは0.1.0となります。別のバージョンが必要な場合は、別の値を入力してください。
• リポジトリから読み取る：リリースコミット時点でコード内に記載されているバージョンをCoroidが読み取ります。対象ファイルはVERSION、package.json、 app.json（Expo）,pubspec.yaml、AndroidのGradleファイル,Cargo.toml、 pyproject.tomlやXcodeプロジェクト内、あるいは指定したファイル内からのみバージョンを取得します。もしファイル内に以前のリリースで使用したバージョンが残っている場合、Coroidは事前にその番号を増やすよう促します。
• 自社のパイプラインが割り当てる：semantic-releaseやタグなどを利用してCI/CDがバージョンを決定し、デプロイ時にその情報を報告します。

各リリースにはビルド番号も付与されます。ビルド番号は常にインクリメントされ、プロジェクト内で再利用されることはありません。これはiOSおよびAndroidのアプリストアが求める要件です。CFBundleVersionとAndroidversionCode。

ビルド処理で受け取る値#

Coroidがリリース用にGitHub ActionsワークフローまたはGitLab CI/CDパイプラインを開始すると、以下の値が渡されます：

GitHubは、ワークフローで宣言されていない入力値を拒否します。そのため、Coroidはそれらを指定したワークフローのみに送信します。オプションとして宣言することも可能です：coroid_version、coroid_build_numberおよびcoroid_release_nameは、それらを列挙するワークフローのみに渡されます。オプションとして宣言してください：

on:
  workflow_dispatch:
    inputs:
      coroid_release_id: { required: true }
      coroid_attempt_id: { required: true }
      coroid_commit_sha: { required: true }
      coroid_environment: { required: true }
      coroid_version: { required: false }
      coroid_build_number: { required: false }
      coroid_release_name: { required: false }

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      APP_VERSION: ${{ inputs.coroid_version || '0.0.0-dev' }}
      APP_BUILD_NUMBER: ${{ inputs.coroid_build_number || '0' }}
      APP_COMMIT: ${{ inputs.coroid_commit_sha || github.sha }}

GitLabはこれらの値を変数として渡すため、特別な宣言は不要です：

deploy:
  script:
    - export APP_VERSION="${COROID_VERSION:-0.0.0-dev}"
    - export APP_BUILD_NUMBER="${COROID_BUILD_NUMBER:-0}"
    - export APP_COMMIT="${COROID_COMMIT_SHA:-$CI_COMMIT_SHA}"

単独で実行されるパイプラインでは独自の値を使用できます。下記の手順に従ってデプロイしたバージョンを報告し、リリース情報に反映させてください。

リリースマニフェストを作成する#

あらゆるプラットフォームで利用できる最も簡単な方法は、ビルド時に小さなファイルを作成し、バージョン表示が必要な箇所でそれを読み取ることです：

cat > release.json <<EOF
{
  "version": "$APP_VERSION",
  "buildNumber": "$APP_BUILD_NUMBER",
  "commitSha": "$APP_COMMIT",
  "releaseName": "${COROID_RELEASE_NAME:-}",
  "environment": "${COROID_ENVIRONMENT:-local}"
}
EOF

ウェブアプリやサービスでは、/version.jsonでこのファイルを配信します。これによりCoroidがチェック用のURLを取得できます（下記参照）。

レシピ#

ウェブアプリ（Next.js、Vite）#

ブラウザで必要な値は、バンドル生成時に設定する必要があります：

NEXT_PUBLIC_APP_VERSION="$APP_VERSION" NEXT_PUBLIC_APP_COMMIT="$APP_COMMIT" npm run build
VITE_APP_VERSION="$APP_VERSION" npm run build

フッターや「About」画面にprocess.env.NEXT_PUBLIC_APP_VERSIONまたはimport.meta.env.VITE_APP_VERSIONを表示し、ビルド前にrelease.jsonをpublicフォルダ内に配置します。

サーバーおよびAPI#

起動時に値を読み取り、バージョンエンドポイントで応答します：

app.get('/version.json', (_request, response) => {
  response.json({
    version: process.env.APP_VERSION,
    buildNumber: process.env.APP_BUILD_NUMBER,
    commitSha: process.env.APP_COMMIT,
  });
});

Dockerイメージ#

値をビルド引数として渡し、イメージにラベルを付けることで、実行中のコンテナとレジストリの両方でバージョンを把握できます：

ARG APP_VERSION=0.0.0-dev
ARG APP_COMMIT=unknown
ENV APP_VERSION=$APP_VERSION APP_COMMIT=$APP_COMMIT
LABEL org.opencontainers.image.version=$APP_VERSION \
      org.opencontainers.image.revision=$APP_COMMIT

docker build --build-arg APP_VERSION="$APP_VERSION" --build-arg APP_COMMIT="$APP_COMMIT" .

iOS#

Xcodeは、App Storeに表示されるバージョンをMARKETING_VERSIONから読み取り、ビルド番号をCURRENT_PROJECT_VERSION：

xcodebuild -scheme App -configuration Release archive \
  MARKETING_VERSION="$APP_VERSION" \
  CURRENT_PROJECT_VERSION="$APP_BUILD_NUMBER"

fastlaneを使用する場合は、increment_version_number(version_number: ENV["APP_VERSION"])およびincrement_build_number(build_number: ENV["APP_BUILD_NUMBER"])。

Android#

次の値を読み取る：app/build.gradle.kts：

android {
    defaultConfig {
        versionName = System.getenv("APP_VERSION") ?: "0.0.0-dev"
        versionCode = (System.getenv("APP_BUILD_NUMBER") ?: "1").toInt()
    }
}

BuildConfig.VERSION_NAMEその後、アプリ内にバージョンを表示します。

Flutter#

flutter build appbundle --build-name="$APP_VERSION" --build-number="$APP_BUILD_NUMBER"
flutter build ipa --build-name="$APP_VERSION" --build-number="$APP_BUILD_NUMBER"

ExpoおよびReact Native#

次の値を読み取る：app.config.js：

export default {
  expo: {
    version: process.env.APP_VERSION ?? '0.0.0-dev',
    ios: { buildNumber: process.env.APP_BUILD_NUMBER ?? '1' },
    android: { versionCode: Number(process.env.APP_BUILD_NUMBER ?? 1) },
  },
};

デプロイしたバージョンを報告する#

デプロイイベントでは、デプロイされたバージョンとビルド番号が記録されます。次のコードを追加してください：versionおよびbuildNumber既存のパイプラインから送信されるイベントにこれらを含めてください：

{
  "schemaVersion": 1,
  "eventId": "ci:run-812:production:succeeded",
  "providerRunId": "run-812",
  "projectId": "<project-uuid>",
  "environmentKey": "production",
  "repository": "owner/repository",
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "status": "succeeded",
  "occurredAt": "2026-09-28T12:00:00Z",
  "version": "1.4.0",
  "buildNumber": "42"
}

プロジェクトのパイプラインでバージョンが割り当てられている場合、リリースには報告されたバージョンが使用されます。そうでない場合、リリースページには報告されたバージョンが表示され、リリース内容との差異が示されます。Coroid上でホストされるプロジェクトの場合、次の値を設定してください：repositoryプロジェクトIDとして設定します。デプロイイベントとCIセットアップイベントの詳細についてはこちらを参照してください。

実行中の内容を確認する#

各環境にバージョンURLを割り当てます。例：https://app.example.com/version.json。デプロイが成功すると、Coroidが該当URLを開き、コミットSHAまたはバージョンを確認します。報告されたコミットはリリースコミットと一致する必要があり、そうでない場合はバージョンが一致する必要があります。ロールアウトが完了するまで10分間継続的にチェックし、その後以下を表示します：検証済み、バージョンが異なるまたは接続不可「実行中の内容」の下に表示されます実行中の内容リリースページに表示されます。

URLはHTTPSかつ公開アドレスである必要があります。Coroidはリダイレクトを追跡せず、最大64KBまでのデータのみを読み取ります。

Coroidにセットアップを依頼する#

バージョン刻印のセットアップ「バージョニング」画面で「バージョン刻印のセットアップ」を選択すると、新規作業が開始され、プロジェクトで検出されたスタックに合わせた要求が作成されます。エージェントはビルド時に上記の値を読み取り、アプリ内にバージョンを表示し、次のコードを書き込みます：release.json、ワークフロー入力を宣言し、READMEに文書化します。要求をレビューした後、通常の作業と同様に進めてください。

関連項目#

• リリース設定
• デプロイイベントとCIセットアップ
• リリース