Inclure la version dans votre build

Les utilisateurs de votre logiciel doivent savoir quelle version ils utilisent. Coroid attribue à chaque version un numéro de build, les transmet au pipeline de compilation, puis vérifie que l'environnement exécute bien la version déployée.

Tous les paramètres sur cette page sont configurés par projet dans Versions → Paramètres de version → Versioning.

Origine du numéro de version#

Choisissez une source par projet :

• Coroid l'attribue (par défaut) : Coroid suggère le prochain numéro de version lors de la préparation d'une version. Il incrémente le dernier chiffre de la version la plus récente déjà publiée par le projet, ainsi 1.4.0 est suivi par 1.4.1. La première version est 0.1.0. Saisissez un autre numéro de version si nécessaire.
• Lire le numéro de version depuis le dépôt: Coroid lit le numéro de version déclaré dans votre code au moment du commit de version. Il recherche dans VERSION, package.json, app.json (Expo), pubspec.yaml, le fichier Gradle Android, Cargo.toml, pyproject.toml et le projet Xcode, ou uniquement dans le fichier que vous spécifiez. Si le fichier contient encore un numéro de version utilisé lors d'une version précédente, Coroid vous demandera de l'incrémenter d'abord.
• Mon pipeline l'attribue: votre CI/CD sélectionne le numéro de version, par exemple via semantic-release ou à partir d'une balise, puis le communique lors du déploiement.

Chaque version reçoit également un numéro de build. Les numéros de build ne diminuent jamais et ne sont pas réutilisés au sein d'un même projet, conformément aux exigences des boutiques d'applications iOS CFBundleVersion et Android versionCode.

Ce que reçoit le processus de compilation#

Lorsque Coroid lance un workflow GitHub Actions ou un pipeline GitLab CI/CD pour une version, il transmet ces valeurs :

GitHub rejette les entrées non déclarées par un workflow. Ainsi, Coroid envoie seulement coroid_version, coroid_build_number et coroid_release_name à un workflow qui les liste. Déclarez-les comme optionnels :

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 transmet les valeurs sous forme de variables, donc aucune déclaration n'est nécessaire :

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}"

Un pipeline exécuté indépendamment peut utiliser ses propres valeurs. Communiquez le numéro de version déployé, comme décrit ci-dessous, afin que la version soit affichée correctement.

Rédiger un manifeste de version#

La méthode la plus simple fonctionnant sur toutes les plateformes consiste à créer un petit fichier pendant la compilation et à le lire là où le numéro de version doit être affiché :

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

Pour une application web ou un service, servez le fichier à /version.json. Cela fournit également à Coroid une URL pour vérifier (voir ci-dessous).

Recettes#

Applications web (Next.js, Vite)#

Les valeurs nécessaires au navigateur doivent être définies lors de la compilation du bundle :

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

Afficher process.env.NEXT_PUBLIC_APP_VERSION ou import.meta.env.VITE_APP_VERSION dans le pied de page ou sur l'écran À propos, et copier release.json dans le dossier public avant la compilation.

Serveurs et API#

Lire les valeurs au démarrage et répondre sur un point de terminaison de version :

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

Images Docker#

Transmettre les valeurs en tant qu'arguments de compilation et étiqueter l'image, afin que le conteneur en cours d'exécution et le registre connaissent tous deux le numéro de version :

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 lit le numéro de version affiché dans l'App Store depuis MARKETING_VERSION et le numéro de build depuis CURRENT_PROJECT_VERSION:

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

Avec fastlane, utilisez increment_version_number(version_number: ENV["APP_VERSION"]) et increment_build_number(build_number: ENV["APP_BUILD_NUMBER"]).

Android#

Lisez les valeurs dans 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 puis affiche la version dans l'application.

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 et React Native#

Lisez les valeurs dans 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) },
  },
};

Signalez la version que vous avez déployée#

Un événement de déploiement peut indiquer quelle version et quel numéro de build ont été déployés. Ajoutez version et buildNumber à l'événement que votre pipeline envoie déjà :

{
  "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"
}

Si le pipeline du projet attribue des versions, la version de la release reprend celle signalée. Sinon, la page de la release affiche la version signalée et indique quand elle diffère de la release. Pour un projet hébergé sur Coroid, configurez repository avec l'ID du projet. Événements de déploiement et configuration CI décrit le reste de l'événement.

Vérifiez ce qui est en cours d'exécution#

Attribuez à chaque environnement une URL de version, comme https://app.example.com/version.json. Après un déploiement réussi, Coroid ouvre l'URL et recherche le SHA du commit ou la version. Un commit signalé doit correspondre au commit de la release ; sinon, la version doit correspondre. Coroid continue à vérifier pendant dix minutes pendant que le déploiement se termine, puis affiche Vérifié, Version différente ou Non joignable sous Ce qui est en cours d'exécution sur la page de la release.

L'URL doit utiliser HTTPS et être accessible publiquement. Coroid ne suit pas les redirections et lit au maximum 64 Ko.

Laissez Coroid le configurer#

Configurer le marquage de version sur l'écran de versioning ouvre Nouveau travail avec une demande rédigée pour la pile détectée du projet. Un agent lit les valeurs ci-dessus au moment du build, affiche la version dans l'application, écrit release.json, déclare les entrées du workflow et documente tout cela dans le README. Examinez la demande, puis poursuivez comme pour tout autre travail.

Lié#

• Paramètres de release
• Événements de déploiement et configuration CI
• Versions