Feat build2

D’après la branche de @adewarumez mais en reprenant correctement depuis develop et non d’un commit antérieur.

Inchangé par rapport à develop

• glide est installé dans une image Docker de build de base afin de ne pas avoir à se reposer sur un glide présent dans le sysème hôte lors de la construction dans Docker, les dépendances sont donc clonées dans l’image de build et ne contaminent pas l’hôte
• Renommage de quelques target (comme docker_build qui devient docker_release pour faire le parallèle avec release)
• Utilisation du Makefile pour la CI avec la target docker_test_image

Rapporté/adapté depuis la branche de @adewarumez:

• Réintroduction des Makefile par projet : ils incluent les target communes qui peuvent être redéfinies dans le Makefile :
• Options de lancement des images docker via le Makefile
• Il est bien possible de maximiser l’utilisation du cache Docker en utilisant du multistage build, de fait, un seul Dockerfile pour construire les images des binaires dans cmd/
• Variable de Makefile SKIP_DEPENDENCIES : exemple : make SKIP_DEPENDENCIES=true va sauter l’étape de pull des dépendances avec DEP_MANAGER, laissant la responsabilité à l’appelant. En l’occurrence, lorsqu’on utilise la target docker_release, les dépendances sont initialisées sur l’hôte pour les avoir en local, puis au sein de Dockerfile.release on fait appel à make release SKIP_DEPENDENCIES=true. La responsabilité de la disponibilité de DEP_MANAGER est laissée à l’appelant.

Changements

• Les target sont cohérentes entre elle : docker_release fait appel à release dans un environnement docker, etc.
• La target par défaut de Makefile.cmd est build et non clean
• La variable d’environnement VERSION est à utiliser au lieu de TAG pour changer la version de l’archive de release, dans les binaires etc…
• La CI va construire une image de test pour chaque JOB à réaliser, contrairement à maintenant où on est toujours sur latest, ce qui empêche le lancement de tests en parallèle
• La CI va nettoyer l’image précédemment construite
• Le build des images docker utilise un maximum le cache (COPY aux bons endroits etc…)

Ajouts

• La target docker_release permettant de construire l’archive de release dans un environnement Docker, permettant le cross-build en quelque sorte. S’il faut à un moment donné intégrer une lib en C dans le projet, on pourra construire très simplement les release pour n’importe quelle plateforme.

Non rapporté depuis la branche de @adewarumez

Le flag NO_GO

Voir SKIP_DEPENDENCIES

release à la racine

Les archives de release sont dans un dossiers releases/ et non à la racine du projet

cmd/projet/Makefile

La variable BINARY n’a pas besoin d’être settée

Le fichier Makefile.var est un fichier ne contenant aucune target, uniquement des varibles, comme son nom l’indique, et le fichier Makefile.cmd contient les target pour construire les binaires et images docker pour cmd/<projet>.

Alpine

On conserve alpine pour construire. Si l’argument d’une possible connexion lente pour le pull des dépendances et compréhensible, la même chose est de mise pour les images docker utilisées.

Les variables GOLANG_IMAGE_RUN et GOLANG_IMAGE_BUILD, dans les Makefiles, permettent de changer cette image.

Exemple :

make docker_release GOLANG_IMAGE_RUN=debian:stretch-slim GOLANG_IMAGE_BUILD=golang:1.10.2-stretch

Cela pourrait être utile en cas de problème du genre segfault qu’on a bien connu avec xmlsec et python.

@adewarumez @bdubois @rhennuyer @tgosselin