Dépôt de test de la procédure automatisée de construction de paquets basée sur les tags release/*, build/* et pkg/*.
Le tag déclencheur doit être de type build/* et être posé sur un commit d’une branche de packaging contenant les informations de contexte suivantes :
* le niveau, develop, staging ou stable,
* la version cible déterminant le dépôt et le profil à utiliser
Dans cette procédure, aussi bien la forme des tags que celle des branche est donc imposée.
## Les branches
On dispose de trois niveaux de code : _develop_, _staging_ et _stable_.
Les branches de packaging correspondantes prennent la forme : _dist/<distribution>/<version>/develop_, _dist/<distribution>/<version>/staging_ et _dist/<distribution>/<version>/stable_.
## Forme des tags
La procédure s’appuie sur une forme spécifique des tags qui est évaluée côté Jenkins.
### release
Un tag de release est posé sur la branche _stable_ au moment où le développeur estime un état du code publiable.
Le tag prend la forme _release/SemVer_
### build
Un tag de build est posé par le mainteneur du paquet dans l’une des branches de packaging, sur un commit propre à la branche (logiquement (à vérifier), le commit devrait être propre à la branche vu qu’il s’agira d’un commit de merge ou d’un commit avec des changements uniquement dans le répertoire debian.
Ce tag n’a, a priori, pas besoin de véhiculer plus d’informations que ce qui est déjà fourni par la branche support.
C’est ce tag qui permet d’exécuter toutes les étapes de la procédure de construction de paquets.
Dans le déroulement normal de la procédure, Jenkins supprime ce tag (qui ne sert que de déclencheur).
### pkg
Un tag pkg est posé par Jenkins si la procédure de construction de paquets est allée à son terme (construction des paquets et publication de ces paquets sur le dépôt de paquets).
Le tag pkg doit fournir certaines informations dont le niveau de packaging et le nom du paquet approximatif (le nom exact n’est pas forcément utilisable dans le nom du tag mais dans le commentaire).
Le tag pkg remplit deux offices :
* tenir un décompte des paquets pour savoir comment numéroter le suivant
* marquer un état du code empaqueté dans le dépôt.
Une question reste en suspens : seuls les paquets en stable portent un numéro important ; faut-il ajouter des tags pour les paquets en développement (ce qui implique de mettre en place un moyen de filtrer les tags stable et develop).
