Synkronisering og vedligeholdelse

Cloud-sync og pipeline-sync har forskellige opgaver. Cloud-sync henter projektændringer fra Umbraco Cloud tilbage til Git. Pipeline-sync foreslår en nyere version af bitbucket-pipelines.yml.

Hent ændringer fra Umbraco Cloud

Umbraco Cloud-templaten indeholder sync-cloud-changes. Start den manuelt fra Run pipeline, eller lad den indgå i planlagt vedligeholdelse. Den kører setup, validate-umbraco-cloud-setup og sync uden deployment.

Den selvstændige sync bruger --resolve-environment til at finde Cloud-aliaset fra den valgte branch og SYNC_BRANCHES_WITH_CLOUD:

SYNC_BRANCHES_WITH_CLOUD="main=live;staging=staging"

Eksemplet forbinder main med Cloud-aliaset live. Tilpas det til projektets faktiske miljøer. Der skal være en mapping for den branch, sync kører på.

SYNC_BRANCHES_WITH_CLOUD bestemmer denne sync-mapping. DEPLOY_*_BRANCH bestemmer, hvilke branches der automatisk starter deployment. Ved fuldt Cloud-deployment kommer målet fra deployment-miljøets TARGET_ENVIRONMENT.

Når Cloud-patchen ikke kan anvendes direkte

Sync forsøger først at anvende den oprindelige patch. Hvis det fejler, fjernes hele filsektioner for lokalt untracked filer, som projektets Git-regler ignorerer, og scriptet forsøger igen. Tracked filer og ikke-ignorerede untracked filer bliver i patchen.

Derefter findes en fallback med reduceret kontekst til visse simple ændringer, eksempelvis PackageVersion-linjer og JSON-nøgle/værdi-linjer i Umbraco Deploy-metadata. Hvis hele patchen filtreres væk, afsluttes sync uden en commit.

Kan patchen stadig ikke anvendes, viser loggen en oversigt til manuel synkronisering med berørte filer og reducerede hunks. Brug oversigten til at gennemgå og overføre ændringerne manuelt. Se Logs og fejlfinding.

Hold pipeline-templaten opdateret

Runneren læser versionskommentaren i projektets bitbucket-pipelines.yml og sammenligner den med den publicerede template. Kommentaren har formen:

# ecreo-version: umbraco-cloud.2026-10-20

På main kan runneren foreslå den nye template via en opdateringsbranch og en PR. Det sker også ved almindelige runner-kørsler på main. Den særskilte sync-pipeline er nyttig, når projektet ikke har et deployment, der ellers ville udføre kontrollen.

Start sync-pipeline på main. Den kører kun setup samt runnerens template-kontrol og laver hverken deployment eller Cloud-sync. På feature-branches og i PR-kørsler opretter template-kontrollen ikke opdateringsbranches.

Et fungerende BITBUCKET_API_TOKEN er nødvendigt for automatisk PR-oprettelse. Uden token kan branchen stadig pushes med checkout-credentials, hvis de tillader det. PR’en skal da oprettes manuelt. En fejl ved PR-oprettelsen kan derfor efterlade en opdateringsbranch uden PR.

Gennemgå altid projektets lokale tilpasninger før merge af en template-opdatering.

Samspil med dependency-PRs

Hvis der allerede er en åben dependency-PR til main i samme repository, forsøger template-opdateringen at bruge dens branch og føjer en pipeline-sektion til beskrivelsen. Denne commit bruger ikke [skip ci], så PR-validering kan køre.

Kan dependency-branchen ikke læses eller opdateres, bruges det selvstændige pipeline-PR-flow. En selvstændig template-opdateringscommit bruger normalt [skip ci]. En senere dependency-opdatering bevarer pipeline-filen og dens beskrivelse i den fælles PR.

Automatiske update-PRs beder Bitbucket om at slette source-branchen efter merge. Reviewer-valget er beskrevet under Variabler og miljøer.

Bevidst afvigelse fra templaten

Hvis projektet bevidst vedligeholder sin egen pipeline-template, kan versionskontrollen springes over med:

# ecreo-version: skip

Det slår kontrollen for template-opdateringer fra. Runneren og de centrale grupper hentes stadig på ny ved hver kørsel.

Planlagt vedligeholdelse

Begge templates har scheduled-maintenance, så projektet kan samle vedligeholdelsen i én Bitbucket-schedule.

Variant	Jobs, der kører parallelt
Umbraco Cloud	Cloud-sync, pipeline-sync og dependency-opdateringer
Azure Web Apps	Pipeline-sync og dependency-opdateringer

Vælg main og scheduled-maintenance, når du opretter en schedule i Bitbuckets pipeline-planlægning. Vælg et tidspunkt og interval, som passer til projektet. For Cloud skal main være med i SYNC_BRANCHES_WITH_CLOUD.

Kontrollér token, permissions og Cloud-variabler, før schedule aktiveres. Jobs kører med fail-fast: false, så et fejlet job ikke i sig selv afbryder de andre. Pipeline-stepene skal stadig gennemgås, og oprettede PRs kræver review og merge.

Se også Dependency-opdateringer.