Czy ktoś mógłby mi wyjaśnić ideę artefaktów w procesie budowania?
Mam katalog obszaru roboczego, w którym pobieram kod, aby skompilować i uruchomić moje skrypty Ant itp. Na koniec, w moim przypadku, otrzymuję plik jar, który jest gotowy do zainstalowania. Czy to jest uważane za artefakt?
Gdzie mam powiedzieć mojemu skryptowi kompilacji, aby umieścić plik jar? W katalogu obszaru roboczego? Mój plik jar otrzymuje unikalną nazwę pliku w zależności od takich zmiennych, jak BUILD_IDi takie, jak mogę powiedzieć Jenkinsowi, który plik jar wybrać?
EDYCJA: OK, więc próbowałem zrobić coś takiego:
Ścieżka nie istnieje jeszcze w moim obszarze roboczym, ponieważ skrypt budujący ma ją utworzyć, i oczywiście plików .jari .propertiesnie ma, ponieważ nie zostały jeszcze wygenerowane. Dlaczego więc wyświetla mi się błąd? Wygląda na to, że czegoś mi brakuje.
Ponadto, czy Jenkins usuwa artefakty po każdej kompilacji (nie zarchiwizowane artefakty, wiem, że mogę nakazać mu je usunąć)? W przeciwnym razie dość szybko zablokuje dysk twardy.
Odpowiedzi:
Twoje rozumienie jest poprawne, artefakt w sensie Jenkinsa jest wynikiem kompilacji - zamierzonym wynikiem procesu budowania.
Wspólna konwencja jest umieszczenie wyniku kompilacji do
build,targetlubbinkatalogu.Archiwizator Jenkins może użyć globs (
target/*.jar), aby łatwo wybrać właściwy plik, nawet jeśli masz unikalną nazwę dla każdej kompilacji.źródło
sh 'mvn clean package'Artefakt może być wynikiem procesu budowania. Ważne jest to, że nie ma znaczenia, na jakim kliencie został zbudowany, zostanie przeniesiony z obszaru roboczego z powrotem do mastera (serwera) i tam zapisany z linkiem do kompilacji. Zaletą jest to, że jest wersjonowany w ten sposób, wystarczy skonfigurować kopię zapasową na swoim serwerze głównym i że wszystkie artefakty są dostępne przez interfejs sieciowy, nawet jeśli wszyscy klienci kompilacji są w trybie offline.
Możliwe jest zdefiniowanie wyrażenia regularnego jako nazwy artefaktu. W moim przypadku spakowałem wszystkie pliki, które chciałem przechowywać w jednym pliku o stałej nazwie podczas kompilacji.
źródło
Nie, Hudson / Jenkins samodzielnie nie czyści obszaru roboczego po kompilacji. W procesie kompilacji mogą występować akcje, które usuwają, zastępują lub przenoszą artefakty kompilacji z miejsca, w którym zostały pozostawione. W konfiguracji zadania w zaawansowanych opcjach projektu (które należy rozwinąć) dostępna jest opcja o nazwie „Wyczyść obszar roboczy przed budowaniem”, która wyczyści obszar roboczy na początku nowej kompilacji.
źródło
W Jenkins 2.60.3 istnieje sposób na usunięcie artefaktów kompilacji (a nie zarchiwizowanych artefaktów) w celu zaoszczędzenia miejsca na dysku twardym maszyny kompilacji. W sekcji Ogólne zaznacz opcję „Odrzuć stare kompilacje” ze strategią „Rotacja dziennika”, a następnie przejdź do opcji zaawansowanych. Pojawią się jeszcze dwie opcje związane z zachowywaniem artefaktów kompilacji dla zadania na podstawie liczby dni lub kompilacji.
Ustawienia, które działają w moim przypadku, to wprowadzenie 1 dla „Maksymalna liczba kompilacji do zachowania z artefaktami”, a następnie wykonanie czynności po kompilacji w celu zarchiwizowania artefaktów. W ten sposób wszystkie artefakty ze wszystkich kompilacji zostaną zarchiwizowane, wszystkie informacje z kompilacji zostaną zapisane, ale tylko ostatnia kompilacja zachowa własne artefakty.
Odrzuć opcje starych kompilacji
źródło