Bygget misslyckades utan loggar: så får du fram output

"Build failed." Ingen stack trace, inget compiler-fel, ingen output över huvud taget. Ett bygge som misslyckas utan loggar är det minst användbara meddelande en plattform kan visa, och det betyder vanligtvis något specifikt som är värt att förstå: felet inträffade innan det som producerar loggar hade startat.

Ett bygge består inte av ett enda steg. Det består av fyra, och varje steg kan misslyckas på olika sätt.

De fyra stegen

1. Hämtning av källkoden. Plattformen klonar ditt repository från en ref. 2. Förberedelse av bygget. Den avgör hur bygget ska genomföras — Dockerfile, buildpack eller ett identifierat ramverk. 3. Körning av bygget. Dina kommandon körs. Det här är det enda steget som producerar den output du förväntar dig. 4. Paketering. Resultatet omvandlas till en körbar image.

Om du inte har några loggar alls inträffade felet i steg 1 eller 2. Ditt bygge kördes aldrig, så det kunde inte heller skriva ut något.

Steg 1: källkoden hämtades aldrig

Symptomen är total tystnad och ett snabbt fel — vanligtvis inom femton sekunder.

Vanliga orsaker, i ordning:

• Branchen finns inte. En tjänst som är konfigurerad att deploya master mot ett repository som bytt namn till main. Det här misslyckas direkt och säger nästan ingenting.
• Åtkomsten drogs in. Tokenen eller appinstallationen som fungerade förra månaden togs bort, eller så flyttades repositoryt till en organisation där behörigheten inte längre gäller.
• Repositoryt är privat och anslutningen har löpt ut. Samma typ av fel som ovan; plattformen får en 404 i stället för en 403, eftersom det är vad Git-leverantörer returnerar för privata repositories som du inte kan se.
• En submodule kan inte hämtas. Huvudrepositoryt klonas, men en submodule som använder en SSH-URL misslyckas eftersom buildmiljön saknar en nyckel för den.

Den snabba kontrollen: visar plattformen ett commit-hashvärde för den misslyckade deploymenten? Om inte fick den aldrig tag i källkoden, och inget i din Dockerfile är relevant.

Steg 2: den vet inte hur bygget ska genomföras

Även det här sker tyst, eftersom inget build-kommando har valts ännu.

• Ingen Dockerfile på den plats som konfigurationen anger. En dockerfilePath pekar på en sökväg som har flyttats.
• Ett monorepo utan root. Plattformen tittar i repositoryts root och din tjänst finns i apps/api.
• Det gick inte att identifiera något. Inget känt manifest hittades, så inget buildpack matchade.
• En Dockerfile som inte kan parsas. Ett syntaxfel på rad 1 gör att bygget misslyckas innan något lager körs.

Steg 3: det är här loggarna finns

Om du ser delvis output som avbryts abrupt är du i steg 3, och de två vanligaste orsakerna handlar om resurser snarare än kod:

Slut på minne. Ett bygge som dödas av OOM-reapern hinner inte skriva ut något om det. Loggen stannar helt enkelt mitt i ett steg. TypeScript-, webpack- och Vite-byggen i stora kodbaser råkar regelbundet ut för detta, och kännetecknet är att samma commit bygger utan problem på din laptop, som har mer minne än buildern.

Timeout. Ett bygge som överskrider plattformens gräns avslutas. Samma symptom: outputen stannar i stället för att avslutas.

Båda kan se ut som "inga loggar" om felet inträffar tillräckligt tidigt.

Steg 4: bygget lyckades men kan inte paketeras

Ovanligt och specifikt: bygget lyckades men artefakten är felaktig. En image utan CMD eller ENTRYPOINT, en arkitekturmismatch eller en image som är för stor för plattformens gräns.

Diagnostisk ordning

# 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 den sista outputen är det snabbaste sättet att lokalisera felet. En deployment som tillbringade 0,4 sekunder med kloningen och sedan avslutades med statusen failed har ett fel i steg 1. En som byggde i nittio sekunder och sedan stannade är ett problem i steg 3, sannolikt minnesbrist.

Så får du fram output när det inte finns någon

Tre tekniker, i ordning efter arbetsinsats:

Återskapa begränsningen lokalt. Fråga inte "bygger det på min dator" — bygg det med samma mängd minne som buildern har:

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

Om det återskapar felet har du hittat orsaken, och det handlar om minne snarare än något mystiskt.

Gör bygget mer utförligt. De flesta buildverktyg är tysta som standard om det som är på väg att få dem att avslutas.

# 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

Raden med NODE_OPTIONS är värd att prova separat — ett Node-bygge som dör tyst beror mycket ofta på en heap-gräns, och en höjning av den löser byggen som inte producerade någon diagnostik alls.

Bisektera Dockerfile. Kommentera bort allt efter steget som misslyckas och lägg till RUN echo "reached step N"-markörer. Grovt, men det fungerar när inget annat gör det.

Så minskar du den här typen av problem

Två saker är viktigare än någon felsökningsteknik.

Strömmande loggar i stället för sammanfattade loggar. Om outputen bara visas efter att bygget är klart producerar ett bygge som dödas ingenting, eftersom sammanfattningen skrivs sist. Med streaming har du kvar loggen fram till ögonblicket då bygget dör.

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

Steg som namnges och tidsmäts. "Build failed" är en enda informationsbit. "Clone: 0.4s, build: failed after 94s" räcker för att stryka tre av de fyra orsakerna ovan utan att läsa något mer.

Vanliga frågor

Varför producerar mitt bygge inga loggar alls? För att det misslyckades innan dina build-kommandon kördes — vanligtvis när källkoden hämtades eller när plattformen försökte avgöra hur den skulle bygga den. Inget av dessa steg producerar build-output.

Varför bygger det lokalt men inte på plattformen? Oftast beror det på minnet. Din dator har mer minne än buildern. Återskapa med docker build --memory=2g för att bekräfta det innan du letar någon annanstans.

Vad betyder en logg som stannar mitt i ett steg? Processen dödades i stället för att avslutas. Slut på minne eller en build-timeout är de två kandidaterna, och OOM-killern ger inte processen möjlighet att förklara sig.

Behöver jag en Dockerfile? Inte nödvändigtvis — plattformar kan identifiera vanliga projekttyper och bygga utan en sådan. Men om identifieringen misslyckas är det i sig ett tyst fel utan loggar, så en explicit Dockerfile eliminerar en hel klass av oklarheter.