Logs og fejlfinding

Start med det fejlede pipeline-step og det første script, der melder fejl. Ved en grøn kørsel uden den forventede deployment skal du også kontrollere beskeder om forældede commits og oversprungne grupper.

Find artifacts og detaljerede logs

Deployment- og PR-valideringssteps i standardtemplates publicerer devops/output/** som artifacts. Åbn Artifacts på det relevante step.

devops/output/
  artifact.env
  logs/
    setup__100_set-variables.log
    validate-umbraco-cloud-setup__100_check-required-variables.log
    sync__100_get_latest_deployment.log
    ...
  sources.zip
  deploy-package.zip

ZIP-filerne afhænger af deployment-typen. sources.zip bruges til Umbraco Cloud, mens deploy-package.zip bruges til Azure.

Logfilerne indeholder også verbose-detaljer, som ikke vises i den almindelige CI-log, eksempelvis API-svar og polling-status. Filnavnet viser gruppe og script.

Runneren opsamler output, men et step skal også have artifacts: - devops/output/** i YAML for at Bitbucket publicerer det. Ikke alle maintenance-steps i standardtemplates har denne deklaration. Brug steppets CI-log eller tilføj artifact-deklarationen, hvis I skal gemme detaljer derfra.

Kopien af artifact.env filtrerer linjer med API_KEY og PASSWORD fra. Det er ikke en generel filtrering af alle hemmeligheder. Lokale scripts skal selv undgå at skrive tokens og andre følsomme værdier i logs og artifacts.

Typiske problemer

Symptom	Kontrollér og ret
Ingen deployment efter push	Matcher branchen DEPLOY_*_BRANCH? Er variablen sat til :? Ligger værdien som ikke-sikret repository-variabel? Et tag-push deployer ikke
Flere deployment-kørsler efter samme push	Er samme branch valgt til flere miljøer? Findes der både push-triggers og ekstra branch/default-deployment-selektorer?
Grøn pipeline uden deployment	Se efter beskeden om en nyere commit. En forældet kørsel kan afslutte succesfuldt uden deployment, hvis den ikke kan stoppes via API
Cloud-validering mangler værdier	Kontrollér projekt-id, API-nøgle og TARGET_ENVIRONMENT. Ved selvstændig sync skal den valgte branch kunne opløses via SYNC_BRANCHES_WITH_CLOUD
Deployment rammer forkert miljø	Kontrollér det valgte Bitbucket deployment-miljø og dets TARGET_ENVIRONMENT eller Azure Kudu URL
Azure URL afvises	Brug den fulde HTTPS Kudu URL med .scm. og /api/zipdeploy
Solution findes ikke	Kontrollér SOLUTION_ROOT_DIR. .sln eller .slnx skal ligge direkte i den mappe
.NET bygger, men tests opdages ikke af scriptet	Scriptets projektsøgning bruger *.Tests.csproj. Kontrollér navngivning og placering
Frontend-validering springes over	Kontrollér WEB_PROJECT_DIR, package-lock.json og npm-scripts. Valideringen finder projekter via lockfiler
Frontend-build fejler	Kontrollér package-lock.json direkte i WEB_PROJECT_DIR, samt npm ci og build-scriptet. Build-gruppen er blokerende
npm-fallback-build fejler, men valideringen er grøn	Det er den forventede fallback-adfærd uden test-script. Et senere deployment-build skal stadig lykkes
Dependency-preflight fejler	Kontrollér token, læseadgang til PRs, værktøjer, solution-sti og rent arbejdstræ. Sørg for, at runtime-mapper er gitignored
Eksisterende dependency-PR opdateres ikke	Kontrollér API-læseadgang og manuelle commits på automationsbranchen. Manuelle commits stopper automatisk branchopdatering
En update-branch findes uden PR	Branch-push kan lykkes, selv om PR-oprettelsen fejler. Kontrollér token og PR-rettigheder, og opret om nødvendigt PR manuelt
Ingen reviewer på automatisk PR	Kontrollér AUTOMATION_PR_REVIEWERS, tokenets læserettigheder og loggens forklaring. PR-forfatteren kan ikke vælges automatisk
Et centralt fix har ingen effekt i projektet	Se efter et lokalt script med samme gruppe og filnavn under devops/steps/. Det lokale script erstatter den centrale version
CDN-reference bliver ikke opdateret	Kontrollér politik, udbyder, versionsudtryk, filplacering og advarsler. Se siden om CDN-opdateringer

Cloud-sync kan ikke anvende en patch

Læs sync-loggens manuelle oversigt over filer og hunks. Kontrollér, om de relevante ændringer allerede helt eller delvist findes i projektet, eller om lokale ændringer giver en konflikt.

Scriptet filtrerer kun lokalt untracked og ignorerede filer efter den første fejl. At føje en tracked fil til .gitignore fjerner den derfor ikke fra patchen.

Overfør de nødvendige ændringer manuelt i en arbejdsbranch, og gennemgå dem som en almindelig kodeændring. Kør derefter den relevante validering og sync igen.

Oplysninger ved intern hjælp

Del pipeline-link, branch, buildnummer, deployment-miljø og navnet på det fejlede script. Vedlæg den relevante log og fejltekst efter kontrol for hemmeligheder. Beskriv også lokale overrides og eventuelle advarsler lige før fejlen.

Tilbage til oversigten.