|
| 1 | +# Procédure pour le patch avec une version antérieure au dernier tag |
| 2 | + |
| 3 | +Si la version du patch est antérieure à la dernière version réalisée, la procédure sur la création du tag est différente. |
| 4 | + |
| 5 | +Ici, nous prendrons comme exemple pour illustrer la démarche un patch avec pour tag **1.2.1** dans un environnement ayant les tags suivants: |
| 6 | + |
| 7 | +``` |
| 8 | +Tag : |
| 9 | + |- 1.4.0 |
| 10 | + |- 1.3.0 |
| 11 | + |- 1.2.0 |
| 12 | + |- 1.1.0 |
| 13 | + |- ... |
| 14 | + |- 0.1.0 |
| 15 | +``` |
| 16 | + |
| 17 | +Voici la liste des actions: |
| 18 | +- [ ] Créer une branche |
| 19 | +- [ ] Tester le patch |
| 20 | + - [ ] 1. En local |
| 21 | + - [ ] 2. Lancer un build sur Jenkins |
| 22 | + - [ ] 3. Le cluster |
| 23 | +- [ ] Pousser la branche sur Github |
| 24 | +- [ ] Créer le tag |
| 25 | + - [ ] Mettre à jour le changelog |
| 26 | +- [ ] Gitlab to Github |
| 27 | +- [ ] CI Github à vérifier |
| 28 | +- [ ] Pypi à vérifier |
| 29 | +- [ ] Faire une communication sur la release (si besoin) |
| 30 | + |
| 31 | +Ci-dessous les explications pour chacune des actions. |
| 32 | + |
| 33 | + |
| 34 | +## Créer une branche |
| 35 | + |
| 36 | +Tout d'abord créer une branche en faisant attention de se mettre sur la version sur laquelle nous souhaitons appliquer le patch (ici 1.2.0). Et y ajouter les commits nécessaires au patch. |
| 37 | + |
| 38 | +Exemple de commande: |
| 39 | +```python |
| 40 | +git switch -c release-1.2.1 1.2.0 |
| 41 | +``` |
| 42 | + |
| 43 | +:warning: vérifier le fichier setup.cfg et, si nécessaire, le mettre à jour pour assurer la compatibilité du patch avec les versions appropriées des dépendances. |
| 44 | + |
| 45 | +## Tester le patch |
| 46 | + |
| 47 | +Le but ici est de vérifier sur plusieurs supports que le patch est fonctionnel. Pour chacune des sous-parties ci-dessous, si l'une d'elles, lève une/des erreur(s), il est nécessaire de les corriger. |
| 48 | + |
| 49 | +### 1. En local |
| 50 | + |
| 51 | +Commencer par cloner le répertoire et sur la branche du patch vérifier : |
| 52 | + - que l'installation est réalisable (`make install`) |
| 53 | + - les tests (`make test`) |
| 54 | + - les notebooks (`make test-notebook`) + lancement manuel pour vérifier les affichages |
| 55 | + - le format des fichiers avec `black`, `mypy` et `pylint` (`make format`, `make lint`) |
| 56 | + |
| 57 | +:exclamation: Ne passer à l'étape suivante qu'une fois les vérifications ok. |
| 58 | + |
| 59 | +Pour passer à l'étape suivante, la branche du patch doit alors être poussée sur gitlab. Voici la ligne de commande pour l'exemple |
| 60 | +```shell |
| 61 | +git push origin release-1.2.1 |
| 62 | +``` |
| 63 | + |
| 64 | +### 2. Lancer une CI Jenkins |
| 65 | + |
| 66 | +Sur Jenkins, lancer un build de CI avec l'option *Build with parameters*. Cela permet d'être sûr que les variables qui surchargent l'environnement sont les bonnes. |
| 67 | + |
| 68 | +Bien renseigner la branche créée pour le patch et la version de pandora nécessaire. |
| 69 | + |
| 70 | +### 3. Le cluster |
| 71 | + |
| 72 | +Cette étape peut-être réalisée en parallèle de la précédente. |
| 73 | + |
| 74 | +Voici la liste des tâches: |
| 75 | + |
| 76 | +1. Se connecter au cluster : |
| 77 | + ```shell |
| 78 | + |
| 79 | + ``` |
| 80 | + |
| 81 | +2. Si les dépôts git nécessaires au test ne sont pas présents, les cloner. Voici un exemple de commande pour le plugin libsgm: |
| 82 | + ```shell |
| 83 | + git clone [email protected]:3d/PandoraBox/pandora_plugins/plugin_libsgm.git |
| 84 | + ``` |
| 85 | + |
| 86 | +3. Faire les installations |
| 87 | + |
| 88 | +4. Lancer une execution de pandora avec les options, ici le plugin libsgm. Voici un exemple de commande pour réserver un noeud avant de lancer le run: |
| 89 | + ```shell |
| 90 | + unset SLURM_JOB_ID |
| 91 | + srun -A cnes_level2 -N 1 -n 8 --time=02:00:00 --mem=64G --x11 --pty bash |
| 92 | + ``` |
| 93 | + Les scripts pour une execution de Pandora se trouve dans le dossier *data_samples*. Voici un exemple de commande sans utilisation de plugin: |
| 94 | + ```shell |
| 95 | + pandora a_local_block_matching.json <répertoire_de_sortie> |
| 96 | + ``` |
| 97 | + :warning: attention le chemin des images dans le json fait que ces dernières sont dans le même dossier que le fichier de configuration. |
| 98 | + |
| 99 | +:warning: Pour la suite, vérifier également la version de Python utilisée. Actuellement il s’agit de la 3.8. |
| 100 | + |
| 101 | + |
| 102 | +5. Vérifier que l'exécution se déroule normalement ainsi que son résultat. |
| 103 | + - Le dossier résultat contient la(les) carte(s) de disparité(s) ainsi qu'un dossier cfg. |
| 104 | + |
| 105 | +6. Lancer les notebooks. |
| 106 | + |
| 107 | +:sunny: **Si tous les tests local/Jenkins/cluster sont ok, alors il est possible de passer à l'étape suivante** |
| 108 | +
|
| 109 | +
|
| 110 | +## Mettre à jour le changelog |
| 111 | +
|
| 112 | +Le fichier *CHANGELOG.md* doit être modifié. Pour cela : |
| 113 | +- lister les tickets corrigés pour la release, |
| 114 | +- les classer selon le label #Added, #Fixed, #Changed. |
| 115 | +
|
| 116 | +Une fois le fichier mis à jour, ajouter un commit dédié à cette modification. |
| 117 | +
|
| 118 | +
|
| 119 | +## Pousser la branche sur Github |
| 120 | +
|
| 121 | +Vu qu'une branche a été créée pour le patch, il faut que celle-ci soit sur Github pour que le tag puisse exister ensuite. |
| 122 | + |
| 123 | +Pour cela, il est nécessaire qu'un build dans la CI soit complètement vert pour ne pas avoir à le faire à la main. Un build avec l'option *Build with parameters* est à réaliser. Une fois que celui-ci est entièrement fini et vert, aller sur le numéro de build et cliquer sur le bouton *Replay* dans le menu à gauche. |
| 124 | + |
| 125 | +Il faut alors éditer le Jenkinsfile comme ci-dessous: |
| 126 | + |
| 127 | + |
| 128 | +```diff |
| 129 | +stage("update github") { |
| 130 | +- when { expression { return (env.gitlabActionType == 'TAG_PUSH' || env.gitlabSourceBranch == 'master') } } |
| 131 | ++ // when { expression { return (env.gitlabActionType == 'TAG_PUSH' || env.gitlabSourceBranch == 'master') } } |
| 132 | + // push to github |
| 133 | + steps{ |
| 134 | + sh """ |
| 135 | + // push to our branch from ... |
| 136 | +- git -c http.proxy=http... HEAD:${XXX} |
| 137 | ++ git -c http.proxy=http... HEAD:refs/heads/${XXX} |
| 138 | +... |
| 139 | +``` |
| 140 | +
|
| 141 | +:warning: La variable dans `{XXX}` est à garder, si elle n'est pas dans l'exemple cela est du à un problème markdown non autorisé. |
| 142 | +
|
| 143 | +Et relancer le build sur la CI, normalement une fois le build Jenkins terminé la branche doit se trouver sur Github. |
| 144 | +
|
| 145 | +:warning: Une fois sur Github, il faut vérifier que la CI n'est pas désactivée. Pour cela, aller dans *action*, si aucun message d'alerte n'est affiché et que le dernier workflow est récent, c'est que celle-ci est opérationnelle. Sinon faire en sorte de la remettre en route. |
| 146 | +
|
| 147 | +## Créer le tag |
| 148 | +
|
| 149 | +Avant de créer le tag, faire un rebase interactif pour faire du propre dans les commits si plusieurs corrections ont dû être faites précédemment. |
| 150 | +
|
| 151 | +Ensuite, aller sur gitlab par le biais d'un browser et se rendre sur le projet en question. Créer le tag en faisant attention de bien choisir la branche créée à cet effet et non master. |
| 152 | +
|
| 153 | +:boom: un build de CI Jenkins est automatiquement lancé sur le projet. |
| 154 | +
|
| 155 | +
|
| 156 | +## Gitlab to Github |
| 157 | +
|
| 158 | +Si un build de CI lancé automatiquement n'est pas vert car la dépendance à pandora n'est pas correcte, un nouveau build avec l'option *Build with parameters* est à réaliser pour ne pas avoir à pousser la branche et le tag à la main sur github. |
| 159 | +
|
| 160 | +Pour cela, dans les champs de *Build with parameters* mettre le numéro du tag, ici dans l'exemple `refs/tags/1.2.1` et mettre la bonne version de pandora. |
| 161 | +
|
| 162 | +A la fin du build, qui est normalement ok, le tag n'est pas poussé sur github. Il faut alors faire *Replay* en modifiant le fichier comme ci-dessous: |
| 163 | +
|
| 164 | +```diff |
| 165 | + stage("update github") { |
| 166 | +- when { expression { return (env.gitlabActionType == 'TAG_PUSH' || env.gitlabSourceBranch == 'master') } } |
| 167 | ++ // when { expression { return (env.gitlabActionType == 'TAG_PUSH' || env.gitlabSourceBranch == 'master') } } |
| 168 | +... |
| 169 | +``` |
| 170 | +Et relancer un build. Une fois celui-ci terminé, aller sur Github pour vérifier que le tag a bien été poussé. Là, la CI Github va de nouveau effectuer un build. Si celle-ci est ok, alors le tag sera poussé sur pypi. |
| 171 | +
|
| 172 | +Dans le cas contraire, supprimer le tag sur Github et ensuite gitlab. Puis, faire les modifications nécessaires et lancer un build de CI Jenkins gitlab. Puis reprendre à partir du chapitre **créer le tag**. |
0 commit comments