Grupper og buildforløb

Runnerens --include angiver grupperne og deres rækkefølge. Inden for hver gruppe kører scripts efter filnavn. Behold setup først, så den delte tilstand er klar til de efterfølgende grupper.

Tilgængelige grupper

Gruppe	Opgave
setup	Indlæser projektstandarder og argumenter og opretter artifact.env
validate	Samlet frontend-validering efterfulgt af .NET-validering i Release
validate-frontend	Kører npm-tests eller et ikke-blokerende fallback-build
validate-dotnet	Validerer .NET-solution i Release med tests eller build
validate-umbraco-cloud-setup	Kontrollerer Cloud-projekt-id, API-nøgle og målets miljøalias
validate-azure-web-app-setup	Kontrollerer Azure URL, brugernavn, password og Kudu URL-format
sync	Henter Cloud-ændringer tilbage til repositoryet
build-frontend	Kører npm ci og npm run build, eller genbruger et gyldigt build fra samme kørsel
deploy-umbraco-cloud	Pakker, uploader og deployer til Umbraco Cloud
deploy-azure-web-app	Publicerer webprojektet, pakker output og deployer med Kudu zipdeploy
update-dependencies	Opdaterer NuGet, npm og understøttede CDN-referencer og samler ændringerne i en PR

Rækkefølge ved deployment

Cloud-deployment kører først setup og kontrol af Cloud-variabler. Derefter kommer Cloud-sync, frontend-validering, frontend-build, .NET-validering og deployment.

Azure bruger samme rækkefølge uden Cloud-sync og med Azure-kontrol og Azure-deployment.

Frontend-tests kører dermed før produktionsbuildet, og .NET-valideringen ser de genererede frontend-filer. Brug de separate valideringsgrupper i dette forløb. validate er fortsat tilgængelig til PR-pipelines og projekter, der bruger den samlede validering.

Frontend-validering og build

Frontend-valideringen finder npm-projekter via package-lock.json under WEB_PROJECT_DIR. Mapper med node_modules, bin og obj springes over.

Projektets scripts	Validering
Et udfyldt test-script	Kør npm ci og derefter npm test. Fejl stopper valideringen
Intet test-script, men et build-script	Kør npm ci og derefter npm run build. Fejl i buildet giver en advarsel
Ingen af delene	Spring npm-valideringen over

Et fejlet npm ci eller en ulæselig package.json får valideringen til at fejle. Manglende WEB_PROJECT_DIR eller manglende lockfiler kan betyde, at npm-valideringen springes over.

Deployment-gruppen build-frontend er strengere. Den kræver WEB_PROJECT_DIR, en package-lock.json direkte i den mappe og et fungerende build-script. Fejl stopper deployment. Et fejlet fallback-build fra valideringen forsøges derfor igen og kan ikke alene godkende deployment.

.NET-validering

Valideringen finder en .sln eller .slnx direkte i SOLUTION_ROOT_DIR, som som standard er repositoryets rod. Den leder efter testprojekter med navnet *.Tests.csproj under samme rod.

Finder den testprojekter, kører den solutionens tests i Release. Ellers bygger den solutionen i Release. Mangler solution-filen, fejler valideringen. Hold derfor navnene på testprojekter og solution-stien i overensstemmelse med denne søgning.

Genbrug af builds

Succesfulde builds registreres i devops/temp/build-state. Genbrug gælder kun inden for én runner-kørsel. Tilstanden nulstilles ved en ny kørsel.

Et succesfuldt fallback-build kan genbruges af build-frontend, når det gælder samme projektmappe og uændrede kilder. npm-tests kører stadig, selv om et build kan genbruges.

Azure-publicering kan bruge --no-build, når der findes et aktuelt, valideret Release-build og webprojektets bin/Release-mappe. Ellers bygger den normalt.

Ændringer i HEAD, tracked filer og ikke-ignorerede untracked kildefiler gør registreringen ugyldig. Cloud-sync og lokale hooks kan derfor udløse et nyt build. Ignorerede genererede filer indgår ikke i kontrollen. Hooks, der ændrer ignorerede kompileringsinput, skal selv ugyldiggøre .NET-buildet som beskrevet i Projektspecifikke scripts.