Build fejlede uden logs: Sådan får du output

"Build fejlede." Ingen stack trace, ingen compiler-fejl, intet output overhovedet. Et build, der fejler uden logs, er den mindst brugbare besked, en platform kan give, og det betyder som regel noget specifikt, som er værd at forstå: Fejlen opstod før det, der producerer logs, blev startet.

Et build er ikke ét trin. Det består af fire, og hvert trin fejler på sin egen måde.

De fire faser

1. Hentning af kildekoden. Platformen cloner dit repository ved en bestemt ref. 2. Forberedelse af buildet. Den finder ud af, hvordan der skal bygges — Dockerfile, buildpack eller et framework, der er blevet identificeret. 3. Kørsel af buildet. Dine kommandoer bliver kørt. Det er den eneste fase, der producerer det output, du forventer. 4. Pakning. Resultatet bliver lavet om til et image, der kan køres.

Hvis du slet ikke har nogen logs, opstod fejlen i fase 1 eller 2. Dit build blev aldrig kørt, så det kunne ikke have skrevet noget.

Fase 1: Din kode blev aldrig hentet

Symptomerne er fuldstændig stilhed og et hurtigt failure — som regel på under femten sekunder.

Typiske årsager, i rækkefølge:

• Branchen findes ikke. En service er konfigureret til at deploye master mod et repository, der er omdøbt til main. Det fejler øjeblikkeligt og siger næsten ingenting.
• Adgangen blev trukket tilbage. Det token eller den app-installation, der virkede sidste måned, blev fjernet, eller repositoryet blev flyttet til en organisation, hvor tilladelsen ikke længere gælder.
• Repositoryet er privat, og forbindelsen er udløbet. Samme situation som ovenfor; platformen får en 404 i stedet for en 403, fordi det er den statuskode, Git-udbydere returnerer for private repositories, du ikke har adgang til at se.
• Et submodule kan ikke hentes. Hovedrepositoryet bliver clonet, men et submodule, der bruger en SSH-URL, fejler, fordi build-miljøet ikke har en nøgle til det.

Det hurtige tjek: Viser platformen et commit-hash for det fejlede deployment? Hvis ikke, fik den aldrig koden, og intet i din Dockerfile er relevant.

Fase 2: Den ved ikke, hvordan den skal bygge

Også lydløst, fordi der endnu ikke er valgt en build-kommando.

• Ingen Dockerfile på den placering, konfigurationen angiver. En dockerfilePath, der peger på en sti, som er blevet flyttet.
• Et monorepo uden en root. Platformen kigger på repositoryets root, mens din service ligger i apps/api.
• Detektion fandt ikke noget. Der er ikke noget genkendeligt manifest, så intet buildpack matchede.
• En Dockerfile, der ikke kan parses. En syntaksfejl på linje 1 får buildet til at fejle, før noget layer bliver kørt.

Fase 3: Det er her, logs findes

Hvis du ser delvist output, der stopper brat, er du i fase 3, og de to mest almindelige årsager handler om ressourcer snarere end kode:

Ikke nok memory. Et build, der bliver dræbt af OOM-reaperen, når ikke at skrive noget om det. Loggen stopper blot midt i et trin. TypeScript-, webpack- og Vite-builds på store codebases rammer jævnligt denne grænse, og et tydeligt tegn er, at det samme commit fungerer fint på din laptop, som har mere memory end builderen.

Timeout. Et build, der overskrider platformens grænse, bliver termineret. Samme symptom: output, der stopper, i stedet for at afsluttes.

Begge dele ligner "ingen logs", hvis fejlen sker tidligt nok.

Fase 4: Det blev bygget, men kan ikke pakkes

Sjældent og specifikt: Buildet lykkedes, men artefaktet er forkert. Et image uden CMD eller ENTRYPOINT, et mismatch mellem arkitekturer eller et image, der er for stort til platformens grænse.

Den diagnostiske rækkefølge

# Is there a commit hash? If not, stage 1.
dockup deployments my-project/my-api --json

# Build logs of the latest deployment, streamed as it goes
dockup logs my-project/my-api --build --follow

# The full record, including which stage took how long
dockup status my-project/my-api --json

stageTimings i det sidste output er den hurtigste måde at lokalisere fejlen på. Et deployment, der brugte 0,4 sekunder på clone og derefter sluttede med status failed, fejlede i fase 1. Et deployment, der brugte halvfems sekunder på at bygge og derefter stoppede, er et fase 3-problem — højst sandsynligt memory.

Sådan får du output, når der ikke er noget

Tre teknikker i rækkefølge efter indsats:

Genskab begrænsningen lokalt. Det handler ikke om, hvorvidt det fungerer på "min maskine" — byg det med den samme mængde memory, som builderen har:

docker build --memory=2g --memory-swap=2g -t test .

Hvis det genskaber fejlen, har du fundet årsagen, og det handler om memory snarere end noget mystisk.

Gør dit build mere detaljeret. De fleste build-værktøjer er som standard stille om det, der er ved at få dem til at gå ned.

# Print progress so a truncated log still shows where it stopped
RUN npm ci --loglevel verbose
RUN NODE_OPTIONS="--max-old-space-size=3072" npm run build

Den NODE_OPTIONS-linje er værd at prøve alene — et Node-build, der dør lydløst, skyldes meget ofte en heap-grænse, og hvis du hæver den, løser det builds, der ikke producerede nogen diagnostik overhovedet.

Bisect Dockerfile. Kommentér alt ud efter det trin, der fejler, og tilføj RUN echo "reached step N"-markører. Det er primitivt, men det virker, når intet andet gør.

Sådan reducerer du denne type problem

To ting betyder mere end enhver debugging-teknik.

Streaming af logs i stedet for opsummerede logs. Hvis output først vises, når et build er færdigt, producerer et build, der bliver dræbt, ingenting, fordi opsummeringen skrives til sidst. Med streaming har du den log, der er tilgængelig frem til det øjeblik, hvor buildet dør.

dockup logs my-project/my-api --build --follow

Faser med navne og tidsmålinger. "Build fejlede" er én bit information. "Clone: 0,4 s, build: fejlede efter 94 s" er nok til at udelukke tre af de fire årsager ovenfor uden at læse mere.

Ofte stillede spørgsmål

Hvorfor producerer mit build slet ingen logs? Fordi det fejlede, før dine build-kommandoer blev kørt — som regel under hentning af kildekoden eller forsøget på at finde ud af, hvordan den skal bygges. Ingen af de to faser producerer build-output.

Hvorfor fungerer det lokalt, men ikke på platformen? Det skyldes oftest memory. Din maskine har mere memory end builderen. Genskab situationen med docker build --memory=2g for at bekræfte det, før du undersøger noget andet.

Hvad betyder en log, der stopper midt i et trin? Processen blev dræbt i stedet for at afslutte. Ikke nok memory eller en build-timeout er de to muligheder, og OOM-killeren giver ikke processen mulighed for at forklare sig.

Har jeg brug for en Dockerfile? Ikke nødvendigvis — platforme kan genkende almindelige projekttyper og bygge uden en. Men hvis detektionen fejler, er det i sig selv et lydløst failure uden logs, så en eksplicit Dockerfile fjerner en hel kategori af uklarheder.