Dockerfile build - czy można zignorować błąd?

112

Mam plik Dockerfile. Podczas budowania obrazu kompilacja kończy się niepowodzeniem z powodu tego błędu:

automake: error: no 'Makefile.am' found for any configure output
Error build: The command [/bin/sh -c aclocal && autoconf && automake -a] returned a non-zero code: 1

który w rzeczywistości jest nieszkodliwy. Biblioteka buduje się dobrze, ale Docker zatrzymuje kompilację po otrzymaniu tego błędu. Czy jest jakiś sposób, żebym mógł poinstruować Dockera, aby to zignorował?

docker dockerfile

— Oskar
źródło

221

Pewnie. Docker po prostu odpowiada na kody błędów zwrócone przez RUNskrypty powłoki w Dockerfile. Jeśli masz Dockerfilecoś takiego:

RUN make

Możesz to zastąpić:

RUN make; exit 0

To zawsze zwróci 0(pomyślny) kod zakończenia. Wadą jest to, że obraz wydaje się pomyślnie budować, nawet jeśli w procesie kompilacji występują rzeczywiste błędy.

— larsks
źródło

2

Przyjechałem tutaj, kiedy próbowałem uciekać service php7-fpm start. Zwróci 1, a RUN zakończy się niepowodzeniem; użycie service php7-fpm start; service php7-fpm statuszałatwia sprawę - wydaje się, że rozwiązuje problem również podczas kompilacji, ponieważ oba polecenia działające osobno mogą sprawić problemy.

— igorsantos 07

Przyszedłem tutaj, kiedy próbowałem zbudować Qt5 ze źródeł. Skompilowałoby się dobrze, ale przy użyciu kompilacji współbieżnej w połączeniu z faktem, że proces kompilacji Qt ma testy czasu kompilacji uruchamiane z make (które celowo zawodzą) moje polecenie RUN zakończyło się z błędem (2). Mamy nadzieję, że to rozwiąże problem!

— Lennart Rolland

34

Może to zainteresować tych, których potencjalne błędy w ich obrazach nie są na tyle nieszkodliwe, aby pozostać niezauważone / zarejestrowane . (Również za mało przedstawiciela do komentowania, więc tutaj jako odpowiedź.)

Jak wskazano, wadą RUN make; exit 0jest to, że nie wiesz, czy twoja kompilacja się nie powiodła. Dlatego raczej użyj czegoś takiego:

make test 2>&1 > /where/ever/make.log || echo "There were failing tests!"

W ten sposób otrzymujesz powiadomienie za pośrednictwem dziennika procesu budowania obrazu dockera i możesz zobaczyć, co dokładnie poszło źle podczas make(lub czegokolwiek innego, nie jest to ograniczone do wykonania).

— mies
źródło

To bardzo niedoceniana odpowiedź. Mój przypadek użycia polegał na tym, że niektóre listy pakietów nie były osiągalne i kończyły się apt-get update -yniepowodzeniem.

— Silviu Burcea

16

Możesz także użyć standardowego błędu ignorowania basha || true, co jest miłe, jeśli jesteś w środku łańcucha:

RUN <first stage> && <job that might fail> || true && <next stage>

— MortenB
źródło

właśnie tego potrzebowałem :) co byłoby jeszcze lepsze to porażka, gdyby praca się nie powiodła, ale po kolejnym etapie (porządki)

— csomakk