Variabler og miljøer

Placér værdierne efter, om de hører til projektet, repositoryet eller et bestemt deployment-miljø.

Placering	Bruges til
devops/.env i Git	Ikke-følsomme projektstandarder, eksempelvis stier og Cloud-sync-mapping
Bitbucket repository variables	Fælles adgang, branchvalg og automatiske reviewers
Bitbucket deployment variables	Destination og adgangsoplysninger for hvert deployment-miljø

Udfyldte argumenter efter -- i runner-kaldet har forrang frem for standardværdier i devops/.env. Standardtemplates sender deployment-adgangsoplysninger som argumenter. Undgå at gentage samme variabel flere steder, da devops/.env også indlæses som Bash og kan overskrive miljøværdier, der ikke blev sendt som argumenter.

Projektstandarder i devops/.env

WEB_PROJECT_DIR="MyProject/Presentation/Website"
SOLUTION_ROOT_DIR="src"
SYNC_BRANCHES_WITH_CLOUD="main=live;staging=staging"
JIRA_KEY="PROJ-0"

Tilpas værdierne til projektet. Cloud-mappingen ovenfor er kun et eksempel.

Variabel	Betydning
WEB_PROJECT_DIR	Webprojektets mappe relativt til repositoryets rod. Frontend-build kører her
SOLUTION_ROOT_DIR	Mappen med .sln eller .slnx. Tom eller udeladt betyder repositoryets rod
SYNC_BRANCHES_WITH_CLOUD	Mapping for selvstændig Cloud-sync i formatet branch=cloud-alias;branch=cloud-alias
JIRA_KEY	Prefix til automatiske commit-beskeder. Prefixet udelades, når værdien er tom

BUILD_NUMBER leveres normalt fra BITBUCKET_BUILD_NUMBER via pipeline-argumentet --build-number.

Repository variables

Opret dem under Repository settings > Pipelines > Repository variables.

Variabel	Hvornår bruges den?	Sikret
UMBRACO_CLOUD_PROJECT_ID	Umbraco Cloud-validering, sync og deployment	Nej
UMBRACO_CLOUD_API_KEY	Adgang til Umbraco Cloud API	Ja
BITBUCKET_API_TOKEN	Stop af forældede pipelines og automatiske PRs. Påkrævet for update-dependencies	Ja
AUTOMATION_PR_REVIEWERS	Valgfri liste over reviewers til automatiske PRs	Nej
DEPLOY_TEST_BRANCH	Automatisk deployment til Test. Standard er main	Nej
DEPLOY_STAGING_BRANCH	Automatisk deployment til Staging. Standard er staging	Nej
DEPLOY_PRODUCTION_BRANCH	Automatisk deployment til Production. Standard er live	Nej

DEPLOY_*_BRANCH og AUTOMATION_PR_REVIEWERS skal ligge i Bitbucket. De bruges før indlæsning af devops/.env. Branchvariablerne skal være ikke-sikrede, så YAML-triggers kan læse dem.

Deployment variables

Gå til Repository settings > Deployments, og vælg hvert miljø separat. Kontrollér både værdier og miljøets deployment-rettigheder.

Variabel	Brug	Sikret
TARGET_ENVIRONMENT	Målets alias. Påkrævet af Umbraco Cloud-validering. Brug det faktiske Cloud-alias	Nej
AZURE_WEB_APP_URL	Fuld Kudu zipdeploy URL for den aktuelle Azure Web App	Nej
AZURE_WEB_APP_USERNAME	Azure deployment-brugernavn	Nej
AZURE_WEB_APP_PASSWORD	Azure deployment-password	Ja

Azure-variablerne bruges kun ved Azure-deployment. En Kudu URL har eksempelvis formen https://my-app.scm.azurewebsites.net/api/zipdeploy. Brug endpointet fra den konkrete Web App.

Bitbuckets deployment-navn og Umbraco Clouds miljøalias kan være forskellige. Bitbucket-miljøet production kan eksempelvis have TARGET_ENVIRONMENT=live. Sæt den korrekte værdi på hvert miljø frem for én fælles repository-værdi. Azure-deployment vælger destination via Kudu URL og kræver ikke TARGET_ENVIRONMENT i den aktuelle template.

Bitbucket-token og rettigheder

Tokenet er valgfrit ved almindeligt build og deployment, men nødvendigt for dependency-opdateringer og automatisk PR-oprettelse.

De eksisterende setup-guides beskriver repository access token-rettighederne Pipelines: Write, Repositories: Write og Pull requests: Write. Hvis tokenopsætningen viser scopes med tekniske navne, skal læseadgang også være med:

Funktion	Nødvendig adgang
Stoppe en ældre pipeline via API	Skriveadgang til Pipelines
Læse commits og vælge reviewer fra main	read:repository:bitbucket
Læse eksisterende PRs og reviewer-historik	read:pullrequest:bitbucket
Oprette og opdatere PRs	write:pullrequest:bitbucket
Opdatere branches	Skriveadgang til repositoryet eller fungerende checkout-credentials til push

PR-skriveadgang alene er ikke tilstrækkelig, når scriptet skal finde eksisterende PRs. Tokenet sendes som Bearer-token af scriptsene.

Uden et fungerende token kan template-opdateringen stadig forsøge at pushe en branch med pipeline-jobbets checkout-credentials. Du skal så selv oprette PR’en. Dependency-pipelinen stopper derimod allerede i sit preflight-check, hvis tokenet mangler.

Reviewers på automatiske PRs

Sæt eventuelt AUTOMATION_PR_REVIEWERS til Bitbucket-bruger-UUID’er med krøllede parenteser og komma mellem værdierne:

{11111111-1111-1111-1111-111111111111},{22222222-2222-2222-2222-222222222222}

Når listen er tom, forsøger løsningen at vælge personen med flest tilknyttede commits blandt de seneste 50 på main. Ved lighed vælges den senest aktive. PR-forfatteren og commits uden en tilknyttet Bitbucket-bruger springes over.

Hvis commit-opslaget fejler eller ikke giver en kandidat, bruges den hyppigste reviewer fra de seneste 20 almindelige PRs efter oprettelsesdato, på tværs af statusser. Hver reviewer tæller én gang pr. PR. Ved lighed afgør den nyeste PR valget. Branches med præfikserne ecreo/dependency-updates-, ecreo/update-pipeline-, dependabot/ og renovate/ udelades, før de 20 PRs udvælges. PR-forfatteren kan heller ikke vælges her.

Eksisterende reviewer-lister bevares. PRs uden reviewers kan få dem tilføjet ved en senere kørsel, også uden nye dependency-ændringer. Fejl i reviewer-tildeling stopper ikke PR-flowet. Loggen viser navn og UUID eller årsagen til, at ingen blev valgt.

Se også Daglig brug og deployment.