Укажите версию в процессе сборки

Пользователям вашего программного обеспечения необходимо видеть, какую версию они используют. Coroid присваивает каждому релизу версию и номер сборки, передает их в конвейер сборки и после этого проверяет, что среда запускает именно тот релиз, который вы развернули.

Все параметры на этой странице задаются отдельно для каждого проекта в Релизы → Настройки релиза → Версии.

Откуда берется версия#

Выберите один источник для каждого проекта:

• Coroid сам назначает её (стандартный вариант): Coroid предлагает следующую версию при подготовке релиза. Он увеличивает последнюю цифру в самой высокой версии, которую уже выпустили для проекта, поэтому 1.4.0 сменяется на 1.4.1. Первый релиз — это 0.1.0. Введите другую версию в любой момент, когда она вам потребуется.
• Считать её из репозитория: Coroid считывает версию, указанную в вашем коде при коммите релиза. Он ищет её в VERSION, package.json, app.json (Expo), pubspec.yaml, файле Gradle для Android, Cargo.toml, pyproject.toml и в проекте Xcode, либо только в указанном вами файле. Если в файле всё ещё указана версия, использованная в предыдущем релизе, Coroid попросит вас сначала её увеличить.
• Мой конвейер сам назначает её: ваш CI/CD выбирает версию, например, с помощью semantic-release или тега, и сообщает о ней при развертывании.

Каждому релизу также присваивается номер сборки. Номера сборок всегда увеличиваются и никогда не повторяются в рамках одного проекта — так требуют магазины приложений для iOS CFBundleVersion и Android versionCode.

Что получает процесс сборки#

Когда 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

Отобразите process.env.NEXT_PUBLIC_APP_VERSION или import.meta.env.VITE_APP_VERSION в нижнем колонтитуле или на экране «О программе», и скопируйте release.json в публичную папку перед сборкой.

Серверы и 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 в качестве идентификатора проекта. События развертывания и настройка CI описывает остальные параметры события.

Проверьте, что запущено#

Назначьте каждой среде URL версии, например https://app.example.com/version.json. После успешного развертывания Coroid открывает этот URL и ищет хэш коммита или версию. Сообщенный коммит должен совпадать с коммитом релиза; в противном случае должна совпадать версия. Coroid продолжает проверку в течение десяти минут до завершения выпуска, затем отображает Проверено, Другая версия или Недоступно под Что запущено на странице релиза.

URL должен использовать протокол HTTPS и быть общедоступным. Coroid не следует за перенаправлениями и считывает не более 64 КБ.

Пусть Coroid настроит это#

Настройте маркировку версий на экране «Версиионирование» открывает страницу Новая работа с запросом, составленным под выявленный стек проекта. Агент считывает указанные выше значения во время сборки, отображает версию в приложении, записывает release.json, определяет входные данные рабочего процесса и документирует их в README. Ознакомьтесь с запросом, затем продолжайте работу как обычно.

Связанное#

• Настройки релиза
• События развертывания и настройка CI
• Релизы