W poprzednim tutorialu umieściłem apke na Jenkins’ie aby mogła się automatycznie budować po zmianach w repo
http://przemek.yum.pl/openshift-2-buduj-w-chmurze-z-jenkins-ci/
Teraz czas na zabawę z setup’em Jenkins’a
- Zacznę od pluginów – zainstalujemy je klikając na Manage Jenkins -> Manage Plugins i już tutaj czeka na nas pierwsza pułapka
W sekcji Available jest no właśnie – nic – przechodzę do zakładki Advanced
i tu klikam na Check Updates. ten proces może potrwać dość długo – nawet kilka minut znane też były problemy z Chrome więc warto uzbroić się w cierpliwość.
W najgorszym przypadku pluginy można dodać z kompa. - Dodaj plugina – oto opisy poszczególnych, które zainstaluje
https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Dashboard+View
https://wiki.jenkins-ci.org/display/JENKINS/Extra+Columns+Plugin
i najważniejsze
https://wiki.jenkins-ci.org/display/JENKINS/Green+Balls - Będziemy jeszcze potrzebować wtyczki którą trzeba zainstalować ręcznie
JBehave plugin do pobrania tu https://nexus.codehaus.org/content/repositories/releases/org/jbehave/jbehave-jenkins-plugin/ i wybieram najnowszą oficjalną wersję, potem należy wybrać plik z rozszerzeniem hpi i mamy wtyczkę 🙂
Gdyby jednak i pozostałe trzeba było ściągnąć – oto linki do nich
http://updates.jenkins-ci.org/download/plugins/xunit/
http://updates.jenkins-ci.org/download/plugins/greenballs/
http://updates.jenkins-ci.org/download/plugins/cobertura/
http://updates.jenkins-ci.org/download/plugins/dashboard-view/
wystarczy klik w permalink i mamy pluginki - Instalujemy je (zakładka Advaced) z kompa lub przez zakładke Available
Po instalacji trzeba zrobić restart Jenkinsa – wbijam pod adres:
https://jenkins-chmura.rhcloud.com/restart no i zatwierdam - Naszym oczom ukazuje się greenball – koniec z dziadowskim niebieskim po udanym buildzie 🙂 Aale wato dodać więcej customu – klikam znak + nad job’em i dodaje Dashboard. Wchodzę na niego i wybieram opcje po prawej stroni Edit View. Teraz można eksperymentować z jakimiś ciekawymi layoutami
Koniec zabawy czas na konfiguracje job’a –
https://jenkins-chmura.rhcloud.com/job/calculator-build/configure
- Max # of builds to keep – jak już wspomniałem tak max 10
- Execute shell to jest ważne pole – znajduje się tu skrypt budowania apki
Co jest ważne – gear build trigger’ujemvn -e clean package -Popenshift -DskipTests'
dlatego trzeba dodać fazę testów do naszego build’a – jest nawet na to przygotowane miejsce pod komentarzem
# Run tests here
Więc dopisuję odpalanie testów i drobne info na konsole
echo Starting tests mvn test
Jeśli chodzi o nadpisanie zmiennej openshift’owej gear build to niestety nie znalazłem rozwiązania i trzeba się z tym męczyć dodając osobno budowanie testów
Dalej są dobrze udokumentowane stepy kopiowania zasobów pomiędzy pre i produkcyjnym środowiskiem oraz informacje o repo itd. - Natepnie dodaję Post-build Action : Publish Cobertura Coverage Report
ustawiam pattern na: **/coverage.xml
Wtyczka prezentuje raport porycia kodu przez testy - Dodaję znów Post-build Action: Publish xUnit test result report
Pod przyciskiem Add wybieram JBehave-3.x i ustawiam pattern an:
**/jbehave/*.xml
Aplikacja testowa którą sugeruje pobrać posiada testy BDD – jeśli w teojej aplikacji takich testów nie ma, można pominąć ten krok – ale zapraszam do tutorialu poświęconego dodawaniu testów BDD do projektu (TODO) - Z pewnych ciekawych powodów wtyczka JBehave nie pozwala na odznaczenie opcji Post-build Action: Publish JUnit test result report z pattern’em **/*Test.xml. (Bo tak nazywam moje unit testy). Zaobserwowałem jednak pewną niestabilność i trzeba czasem pokombinować z dodaniem – usunięciem którejś ze wtyczek – widać kolejność ma znaczenie 🙂 Finalnie dane z testów powinny pochodzić z JBehave i z JUnit a przy padniętym buildzie po stronie unit testów tylko z JUnit. A co się stanie przy padniętych testach JBehave – trzeba sprawdzić 😀
Zapisuję tę ciężką pracę i odpalam build’a – zobaczmy co powie 😀
Już po dwóch build’ach powinien nam się ukazać taki oto widok:
Czas coś w końcu dodać od siebie i zobaczyć jak maszina działa 😛
Wbrew boskim przykazaniom TDD zkodziłem sobie nową metodkę szybko i bezmyślnie
\src\main\java\com\rhcloud\pbtest\calculator\Calculator.java
public void divide(int number1, int number2) {
result = number1+number2;
}
Co na to CI? Pokrycie kodziku spadło – w folderku Workscpace -> target/site/cobertura/index.html po kliknięciu w klasę znalazłem winnego
Dodaję więc klaskę testową już trochę bardziej przytomnie i push’uje na repo :
public class CalculatorDivideTest {
private Calculator calc = new Calculator();
@Test
public void shouldDivideNumberByAnotherNumber(){
calc.divide(4,2);
assertEquals("Divide unsuccessfull", 2, calc.getResult());
}
}
Ola Boga cożech się stało – no tak… (smutek) Build czerwony…
No to szybko do wyników pod linkiem Test Result a tam jak nic jest Test wywalony
calculator.CalculatorDivideTest.shouldDivideNumberByAnotherNumber Error Message Divide unsuccessfull expected:<2> but was:<6> Stacktrace java.lang.AssertionError: Divide unsuccessfull expected:<2> but was:<6>
Fiksuje ten niewybredny błąd w mojej metodzie i wszystko wraca do zieloności 🙂
Warto wiedzieć
- Logi na Jenkis można podglądnąć:
a) Wchodząc w job’a i klikając na ikonkę Ball w Build History
b) Wchodząc w konkretnego build’a w Build History -> Console Output
c) Dodając i konfigurując Extra Collumn plugin – najświeższe logi są dostępne już z job’a – efekt możecie podziwiać na obrazku na początku postu 🙂 - W Manage Jenkins -> Cnfigure System->Default view możemy ustawić naszeg custom’owego dashbord’a 🙂
- Nie trzeba wpadać na Jenkins’a aby szybko podglądnąc jaki był wynik build’a – w terminalu wystarczy wpisać i dostaniemy feedback – to jest generyczne dla każdej openshift’owej apki – czyli można też tak podglądnąć logi apki calculator
rhc tail jenkins
Nov 03, 2013 3:12:44 AM hudson.model.Run execute INFO: calculator-build #59 main build action completed: SUCCESS
- Pliki po zbudowaniu apki w job’ie na testowym workspace są automatycznie kasowane po 15 minutach bezczynności – jednak można to obejść
po pierwsze wydłużając ten czas w ustawieniach Jenkinsa do 60min w Slave Idle Time to Live, Max Slave Idle Time to Live
po drugie dodając nowego jenkins’owego job’a (ustawienia konfiguracyjne trzeba skopiować z głównego job’a [bez git’a, shell’a i plugin’ów ]) i ustawiając cron’a w Build Triggers na np 0,55 * * * * czyli co 55min będzie wykonywał się pusty build więc pliczki nie powinny być kasowane
To by było na tyle odnośnie testów, Jenkins na Openshift. Z pewnością w innych postach będę wspominał o różnych sposobach testowania apki javowej – co z powodzeniem można zastosować w chmurze 🙂 ….
W kolejnym poście opiszę proces dodania bazki i phpMyAdmin do apki na Openshift link (TODO)