Ivy, Ant, Jenkins - Czy to dobry pomysł na <ivy: cleancache> na kompilacjach Jenkinsa?

Question

Zamierzamy używać Ivy z Antem, a będziemy musieli Jenkinsa robić nasze kompilacje. Początkowo sądziłem, że posiadanie Jenkinsa przed <ivy:cleancache/> przed uruchomieniem kompilacji byłoby dobrym pomysłem. (Byłoby to częścią obowiązkowego "czystego" celu).

Jednak teraz widzę, że <ivy:cleancache> nie usuwa po prostu rzeczy z <ivy:cachepath>, ale tak naprawdę usuwa cały katalog $HOME/.ivy/cache.

Moim problemem jest to, że jeśli Jenkins robi <ivy:cleancache> na wszystkie wersje zanim zaczną, będzie kolidować z innymi buduje Jenkins może być wykonywany.

Czy dobry pomysł, zwłaszcza jeśli jeden użytkownik może wykonywać wiele kompilacji jednocześnie?

Co się dzieje, gdy wykonujesz <ivy:cachepath pathid="compile.path"/> w wielu projektach? Czy ma to również wpływ na coś takiego jak Jenkins? Czy Jenkins będzie zdezorientowany, jeśli wiele buildów buduje jednocześnie compile.cachepath?

Answer 1

Moim zdaniem prowadzenie zadania cleancache z bluszczem przy każdej kompilacji jest przesadą i eliminuje jedną z głównych zalet używania bluszczu, inteligentne pobieranie zależności od innych podmiotów.

Mimo, że jak wskazano w poniższej powiązanej Maven pytanie, wszystkie bufory mogą zabrudzone i powinny być okresowo przepłukuje:

When is it safe to delete the local Maven repository?

Kilka zaleceń:

Zastosowanie dedykowane Jenkins pracy (s) w celu wyczyszczenia pamięci podręcznej bluszcza

Moja pierwsza rekomendacja to utworzenie okresowego zadania Jenkinsa, które wywoła następujący cel: "oczyść wszystko" w swojej kompilacji:

<target name="clean-all" depends="clean"> 
    <ivy:cleancache/> 
</target> 

Gwarantuje to, że Jenkins decyduje kiedy cache jest czyszczony i można zaplanować to się wydarzy poza normalnymi czasami budowlanej (na przykład 2 nad ranem w dniu 1 każdego miesiąca)

Isolate każdego projektu przy użyciu wielu buforów

Moja druga rekomendacja zwiększa izolację między Twoimi projektami. Skonfiguruj każdy projekt tak, aby miał własną prywatną pamięć podręczną, korzystając z dyrektywy caches. w twoim pliku ustawień bluszczu.

Answer 2

Oto co Zdecydowałem się zrobić:

I zostały zmodyfikowane mój plik ivysettings.xml mieć następujące:

<ivysettings> 
    <properties environment="env." override="false"/> 
    <caches 
     defaultCacheDir="${ivy.default.ivy.user.dir}/cache-${env.EXECUTOR_NUMBER}" 
     resolutionCacheDir="${ivy.dir}/../target/ivy.cache"/> 
    <settings defaultResolver="default"/> 
    <include file="${ivy.dir}/ivysettings-public.xml"/> 
    <include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/> 
    <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/> 
    <include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/> 
    <include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/> 
</ivysettings> 

ten ma dwie rzeczy:

• Definiuje Ivy lokalna pamięć podręczna jako $HOME/.ivy/cache-$EXECUTOR_NUMBER gdzie $EXECUTOR_NUMBER jest wykonawcą Jenkins. Oznacza to, że każdy wykonawca otrzymuje własną pamięć podręczną bluszczu. Tak więc, jeśli Jenkins wykonuje więcej niż jedno zadanie na raz, każde zadanie zostanie odebrane za pomocą innego executora, więc będzie mieć własną pamięć podręczną. Jeśli zadanie chce wyczyścić pamięć podręczną, może zostać wykonane z wyprzedzeniem.
• Zdefiniowałem pamięć podręczną rozpoznawania na ${basedir}/target/ivy.cache. Daje to każdemu zadaniu własną pamięć podręczną przelicznika, która jest dość mała. Ale w ten sposób rozwiązywanie ivy nie koliduje z innymi zadaniami, jeśli Jenkins buduje wiele poprawek tego samego projektu Ivy.

Jedyną wadą jest to, że domyślny katalog pamięci podręcznej użytkownika nazywa się $HOME/.ivy/cache-$env.EXECUTOR_NUMBER, co nie jest ładną stroną. Chciałbym uczynić to bardziej rozsądnym $HOME/.ivy/cache-0, ale nie doszedłem do tego. W rzeczywistości jednak nie ma to żadnego wpływu.

Teraz programista ma jedną pamięć podręczną Ivy, która zawiera wszystkie słoiki, które pobrały. W ten sposób słoiki mogą być dzielone między projekty, co przyspiesza prace programistów.

Tymczasem Jenkins może czyścić pamięć podręczną bluszcza tak często, jak jest skonfigurowana. Można to zrobić dla każdego zadania lub raz dziennie lub miesięcznie. Jednakże, ponieważ pamięć podręczna jest wykonywana dla każdego executora, nie będę miał problemu z czyszczeniem pamięci podręcznej, podczas gdy inne zadanie (które byłoby uruchomione na innym executorze) zależy od tej pamięci podręcznej.

To powinno rozwiązać wszystkie szczególne problemy. Jedyne, co chciałbym zrobić, to dowiedzieć się, jak ustawić domyślną zmienną EXECUTOR_NUMBER, jeśli jeszcze nie została ustawiona. Próbowałem różnych rzeczy takich jak to:

<ivysettings> 
    <property name="env.EXECUTOR_NUMBER" value="0" override="false"/> 
    <properties environment="env." override="false"/> 
    <caches 
     defaultCacheDir="${ivy.default.ivy.user.dir}/cache-${env.EXECUTOR_NUMBER}" 
     resolutionCacheDir="${ivy.dir}/../target/ivy.cache"/> 
    <settings defaultResolver="default"/> 
    <include file="${ivy.dir}/ivysettings-public.xml"/> 
    <include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/> 
    <include url="${ivy.default.settings.dir}/ivysettings-local.xml"/> 
    <include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/> 
    <include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/> 
</ivysettings> 

Ale na próżno. Zmieniono zmianę parametrów override na obu plikach <property> i <properties> na różne sposoby, ale nie całkiem to, co chcę.

Answer 3

Po prostu coś, co robiłem bardzo dużo, aby rozwiązać ostatni problem.

Można dodać do właściwości Jenkins Ant Budowanie Kroki

another.less.obtrusive.name=${EXECUTOR_NUMBER} 

i dodać do ivysettings.xml.

To będzie "0" dla wszystkich, z wyjątkiem Jenkinsa, ponieważ wprowadzi tę właściwość do ANT.

Coś na główne pytanie: Na Jenkins zawsze zaczynam nowe. Kompilacje CI powinny być solidne, dokładne. Fast jest mile widzianym produktem ubocznym, ale nie motywacją.