Ange versionen i din build

De som använder din programvara behöver se vilken version de kör. Coroid ger varje version ett versionsnummer och ett byggnummer, skickar båda till pipelinen som bygger den och kontrollerar sedan att miljön kör den version du distribuerade.

Allt på den här sidan ställs in per projekt under Versioner → Release settings → Versioning.

Var versionsnumret hämtas från#

Välj en källa per projekt:

• Coroid tilldelar det (standard): Coroid föreslår nästa versionsnummer när du förbereder en version. Det höjer den sista siffran i det högsta versionsnumret som projektet har släppt, så 1.4.0 följs av 1.4.1. Den första versionen är 0.1.0. Ange ett annat versionsnummer när du behöver det.
• Hämta det från repositoryt: Coroid läser versionsnumret som koden anger vid release-committen. Den letar i VERSION, package.json, app.json (Expo), pubspec.yaml, Android Gradle-filen, Cargo.toml, pyproject.toml och Xcode-projektet, eller bara i filen du anger. Om filen fortfarande innehåller ett versionsnummer som användes i en tidigare release ber Coroid dig att höja det först.
• Min pipeline tilldelar det: din CI/CD väljer versionsnumret, till exempel med semantic-release eller från en tagg, och rapporterar det tillsammans med distributionen.

Varje version får också ett byggnummer. Byggnummer ökar alltid och återanvänds aldrig inom ett projekt, vilket är ett krav från appbutikerna för iOS CFBundleVersion och Android versionCode.

Vad bygget får#

När Coroid startar ett GitHub Actions-arbetsflöde eller en GitLab CI/CD-pipeline för en release skickar det dessa värden:

GitHub avvisar indata som ett arbetsflöde inte deklarerar. Därför skickar Coroid coroid_version, coroid_build_number och coroid_release_name bara till ett arbetsflöde som listar dem. Deklarera dem som valfria:

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 skickar värdena som variabler, så ingen deklaration behövs:

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

En pipeline som körs fristående kan använda egna värden. Rapportera versionsnumret du distribuerade enligt beskrivningen nedan, så visas det för releasen.

Skriv ett release-manifest#

Det enklaste sättet som fungerar på alla plattformar är att skriva en liten fil under bygget och läsa den där versionsnumret visas:

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

För en webbapp eller tjänst kan du publicera filen på /version.json. Då får Coroid också en URL att kontrollera (se nedan).

Exempel#

Webbappar (Next.js, Vite)#

Värden som webbläsaren behöver måste anges när bundle-filen byggs:

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

Visa process.env.NEXT_PUBLIC_APP_VERSION eller import.meta.env.VITE_APP_VERSION i sidfoten eller på en Om-skärm, och kopiera release.json till den publika mappen före bygget.

Servrar och API:er#

Läs värdena vid start och svara via en versionsendpoint:

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-avbildningar#

Skicka värdena som byggargument och märk avbildningen, så att både den körande containern och registret känner till versionsnumret:

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 hämtar versionsnumret som visas i App Store från MARKETING_VERSION och byggnumret från CURRENT_PROJECT_VERSION:

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

Med fastlane använder du increment_version_number(version_number: ENV["APP_VERSION"]) och increment_build_number(build_number: ENV["APP_BUILD_NUMBER"]).

Android#

Läs värdena i 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 visar sedan versionsnumret i appen.

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

Läs värdena i 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) },
  },
};

Rapportera versionsnumret du distribuerade#

En distributionshändelse kan ange vilken version och vilket byggnummer som distribuerades. Lägg till version och buildNumber i händelsen som pipelinen redan skickar:

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

Om projektets pipeline tilldelar versionsnummer använder releasen det rapporterade versionsnumret. Annars visar releasesidan det rapporterade versionsnumret och påpekar om det skiljer sig från releasens. För ett projekt som finns på Coroid, ange repository som projekt-ID. Distributionshändelser och CI- konfiguration beskriver resten av händelsen.

Kontrollera vad som körs#

Ge varje miljö en versions-URL, till exempel https://app.example.com/version.json. När en distribution har slutförts öppnar Coroid URL:en och letar efter commit-SHA:t eller versionsnumret. En rapporterad commit måste matcha release-committen, annars måste versionsnumret matcha. Coroid fortsätter att kontrollera i tio minuter medan utrullningen slutförs och visar sedan Verifierad, Annat versionsnummer eller Kan inte nås under Vad som körs på releasesidan.

URL:en måste använda HTTPS och en publik adress. Coroid följer inte omdirigeringar och läser högst 64 KB.

Låt Coroid konfigurera det#

Konfigurera versionsmärkning på skärmen Versionshantering öppnar Nytt arbete med en förfrågan som är anpassad efter projektets identifierade teknikstack. En agent läser värdena ovan när bygget körs, visar versionen i appen och skriver release.json, deklarerar arbetsflödets indata och dokumenterar det i README-filen. Granska förfrågan och fortsätt sedan som med allt annat arbete.

Relaterat#

• Inställningar för versioner
• Driftsättningshändelser och CI-konfiguration
• Versioner