Skip to main content

Aanmaken van een freestyle project

In Jenkins is alles opgebouwd rond projecten, die op één of meerdere servers kunnen uitgevoerd worden.

  • Klik op het dashboard op "New Item" en kies voor Freestyle project
  • Gebruik Mijn Freestyle project als naam voor het eerste project dat we zullen aanmaken.

Configureer de Job​

Voeg je eigen repository met de Flask demo (die je geforked hebt) toe aan het menu "Source code management". Daarvoor zal je ook een private key moeten toevoegen aan je Jenkins installatie, zodat die in jouw naam repo's kan binnen halen.

Doe dit met de nodige omzichtigheid, je werkt met (je eigen) authenticatiegegevens!

Maak hiervoor een nieuw keypair aan op je computer, en voeg die keys toe aan zowel je Jenkins project (private key) als Gitlab (public key). Stel de geldigheid van de key op Gitlab in op slechts enkele weken. Na deze workshop zullen we de key ook terug verwijderen uit Gitlab, zodat je keys steeds veilig blijven.

ssh-keygen -t ed25519 -C "Gitlab key (lab IaC)"

private key

repo_connected

Configuratie van de steps​

  • in het Menu 'Build Steps' in het project kan je build stappen toevoegen. Voeg (onderaan) een 'execute shell' build step toe, met als inhoud
pytest *

Met deze stap willen we controleren de testen in de code allemaal goed verlopen. Anders zal de build step falen. Op deze manier zijn ontwikkelaars extra gemotiveerd om voldoende commentaar te gebruiken, en de regels te volgen ivm naamgeving, ...

Bewaar deze config, en voer deze 'build' manueel uit.

failed_build

Vermoedelijk faalt je build. Bekijk even in de console output wat het probleem is.

failed_build

tip

Deze initiële build fout heeft vermoedelijk te maken met de Host Key Verification. Een eerste connectie via SSH (in dit geval naar Gitlab), daarvan moet je immers de host key aanvaarden. Lees de documentatie (zie Console Output) om dit op te lossen.

Ongetwijfeld faalt je build daarna nog steeds, en de oorzaak daarvan kan je opnieuw vinden in de build output. Welke package ontbreekt nog?

We zouden die ontbrekende package (pytest) nog kunnen installeren in de cli van je linux, manueel, met apt-get.
Maar dit betekent dan dat deze global-wide voor je hele systeem beschikbaar is.
In python willen we typisch per project bepalen met welke versies van de packages we willen werken. De oplossing hiervoor is in python gebruik maken van virtual environments.

caution

Op deze manier merk je ook dat de Jenkins server standaard de build-server als omgeving zal gebruiken voor het doorlopen van z'n build-stappen. Dat is een potentieel probleem, want bij een update van die server zou het dus kunnen gebeuren dat sommige stappen niet meer werken. Beter is om builds in software containers te laten lopen, dan zijn die risico's er veel minder of voor python projecten, op z'n minst in virtual environments. Die werkwijze komt later nog aan bod...

Voer na het toevoegen van het ontbrekende pakketten op de server de build opnieuw uit. De buildstep ziet er nu zo uit:

python3 -m venv venv
. venv/bin/activate
pip3 install -r requirements.txt
pytest app.py

Ook nu krijg je nog een falende build, maar als alles goed gevolgd werd, is dat geen probleem meer in de infrastructuur, maar een echt probleem in de Python-code. Bekijk de output van de test daarvoor in de laatste build status.

failed_build_detail

Los het (eenvoudige) probleem op, en start je build opnieuw.

Als alles goed gaat, dan zou je nu een werkende build moeten zien.

succes_build

Artefacts​

Artefacts vormen de resultaten van de builds die je maakte. Afhankelijk van het type project kan dat erg in vorm verschillen. Dat kan een .exe zijn als je software gaat compileren, maar dan kan ook een zip zijn met bestanden, ...

In deze oefening is de artefact een rapport dat gemaakt wordt en een verslag bevat van de statische verificatietool pylint. Naast een score lees je er ook in welke verbeteringen mogelijk zijn om te voldoen aan de regels van de kunst binnen Python.

Voeg een nieuwe build stap bij ('execute shell')

pylint *.py --exit-zero > report.txt

Vergeet uiteraard niet dat de pylint-package moet geïnstalleerd zijn in de virtual environment. Pas dus de requirements-file aan!

Voeg een post install stap toe ("archive the artefacts") waarin report.txt bewaard wordt. Bij elke nieuwe build zal je nu een rapport kunnen downloaden.

artefact

artefact