Build mislyktes uten logger: Slik får du output

«Build failed.» Ingen stack trace, ingen compiler-feil, ingen output i det hele tatt. En build som mislykkes uten logger er den minst nyttige meldingen en plattform kan gi, og det betyr som regel noe konkret som det er verdt å forstå: Feilen oppstod før det som produserer logger, startet.

En build er ikke ett trinn. Den består av fire, og hvert av dem feiler på sin egen måte.

De fire stadiene

1. Henting av kildekoden. Plattformen kloner repositoryet ditt på en ref. 2. Klargjøring av builden. Den finner ut hvordan builden skal kjøres — Dockerfile, buildpack eller et detektert rammeverk. 3. Kjøring av builden. Kommandoene dine kjøres. Dette er det eneste stadiet som produserer outputen du forventer. 4. Pakking. Resultatet gjøres om til et kjørbart image.

Hvis du ikke har noen logger i det hele tatt, oppstod feilen i stadium 1 eller 2. Builden din ble aldri kjørt, så den kunne heller ikke ha skrevet ut noe.

Stadium 1: Koden din ble aldri hentet

Symptomene er total stillhet og en rask feil — vanligvis på under femten sekunder.

Vanlige årsaker, i prioritert rekkefølge:

• Branchen finnes ikke. En tjeneste som er konfigurert til å deploye master mot et repository som er endret til main. Dette feiler umiddelbart og sier nesten ingenting.
• Tilgangen ble trukket tilbake. Tokenet eller app-installasjonen som fungerte forrige måned, ble fjernet, eller repositoryet ble flyttet til en organisasjon der tilgangen ikke lenger gjelder.
• Repositoryet er privat, og tilkoblingen har utløpt. Samme situasjon som over; plattformen får en 404 i stedet for en 403, fordi det er dette Git-leverandører returnerer for private repositories du ikke kan se.
• En submodule kan ikke hentes. Hovedrepositoryet klones, men en submodule som bruker en SSH-URL, feiler fordi build-miljøet ikke har noen nøkkel til den.

Den raske kontrollen: Viser plattformen en commit-hash for den mislykkede deploymenten? Hvis ikke, fikk den aldri hentet koden, og ingenting i Dockerfile-en din er relevant.

Stadium 2: Den vet ikke hvordan builden skal kjøres

Også stille, fordi ingen build-kommando er valgt ennå.

• Ingen Dockerfile der konfigurasjonen forventer den. En dockerfilePath som peker til en path som er flyttet.
• Et monorepo uten root. Plattformen ser på roten av repositoryet, mens tjenesten din ligger i apps/api.
• Deteksjonen fant ingenting. Ingen gjenkjent manifestfil, så ingen buildpack ble valgt.
• En Dockerfile som ikke kan parses. En syntaksfeil på linje 1 feiler før noe layer kjøres.

Stadium 3: Det er her loggene finnes

Hvis du ser delvis output som stopper brått, er du i stadium 3, og de to vanligste årsakene er ressurser, ikke kode:

Tom for minne. En build som blir drept av OOM-reaperen, får ikke skrevet ut noe om det. Loggen stopper ganske enkelt midt i et trinn. TypeScript-, webpack- og Vite-builder på store kodebaser rammes regelmessig av dette, og kjennetegnet er at den samme commiten bygger fint på laptopen din, som har mer minne enn builderen.

Timeout. En build som overskrider plattformens grense, termineres. Samme symptom: output som stopper i stedet for å avsluttes.

Begge deler kan se ut som «ingen logger» hvis feilen oppstår tidlig nok.

Stadium 4: Den bygget, men kan ikke pakkes

Sjeldent og spesifikt: Builden ble fullført, men artefakten er feil. Et image uten CMD eller ENTRYPOINT, en arkitekturkonflikt eller et image som er for stort for plattformens grense.

Rekkefølgen for feilsøking

# 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 siste outputen er den raskeste måten å finne feilen på. En deployment som brukte 0,4 sekunder på clone og deretter endte som mislykket i stadium 1, peker på et problem i stadium 1. En som brukte nitti sekunder på build og deretter stoppet, er et problem i stadium 3, mest sannsynlig minne.

Slik får du output når det ikke finnes noen

Tre teknikker, sortert etter hvor mye innsats de krever:

Gjenskap begrensningen lokalt. Ikke «bygger den på maskinen min» — bygg den med samme mengde minne som builderen har:

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

Hvis dette gjenskaper feilen, har du funnet årsaken, og det er minne — ikke noe mystisk.

Gjør builden mer detaljert. De fleste build-verktøy er som standard lite tydelige om det som er i ferd med å ta livet av dem.

# 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

Det er verdt å prøve NODE_OPTIONS-linjen alene — en Node-build som dør stille, skyldes svært ofte en heap-grense, og å øke den løser builder som ikke produserte noen feildiagnostikk i det hele tatt.

Bisect Dockerfile-en. Kommenter bort alt etter trinnet som feiler, og legg til RUN echo "reached step N"-markører. Det er enkelt, men fungerer når ingenting annet gjør det.

Hva reduserer denne typen problemer

To ting er viktigere enn enhver feilsøkingsteknikk.

Streaming av logger i stedet for oppsummerte logger. Hvis outputen først vises etter at builden er ferdig, produserer en build som blir drept, ingenting, fordi oppsummeringen skrives til slutt. Med streaming har du loggen frem til øyeblikket builden stoppet.

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

Stadier med navn og tidsmåling. «Build failed» er én bit med informasjon. «Clone: 0,4 s, build: failed after 94 s» er nok til å utelukke tre av de fire årsakene over uten å lese noe mer.

Vanlige spørsmål

Hvorfor produserer builden min ingen logger i det hele tatt? Fordi den feilet før build-kommandoene dine ble kjørt — vanligvis under henting av kildekoden eller mens plattformen fant ut hvordan den skulle bygge den. Ingen av disse stadiene produserer build-output.

Hvorfor bygger den lokalt, men ikke på plattformen? Som oftest minne. Maskinen din har mer minne enn builderen. Gjenskap problemet med docker build --memory=2g for å bekrefte dette før du leter andre steder.

Hva betyr en logg som stopper midt i et trinn? Prosessen ble drept i stedet for å avslutte. For lite minne eller en build-timeout er de to mest sannsynlige årsakene, og OOM-killeren gir ikke prosessen mulighet til å forklare seg.

Trenger jeg en Dockerfile? Ikke nødvendigvis — plattformer kan detektere vanlige prosjekttyper og bygge uten en. Men hvis deteksjonen feiler, er det i seg selv en stille feil uten logger, så en eksplisitt Dockerfile fjerner en hel klasse av uklarheter.