Produits Entr'ouvert » Tests fonctionnels de Publik

Je suis tombé sur une autre option:

diff --git a/Jenkinsfile b/Jenkinsfile
index 3beecb8..f250248 100644
--- a/Jenkinsfile
+++ b/Jenkinsfile
@@ -14,6 +14,11 @@ pipeline {
     }
     stages {
         stage('Build image') {
+            when {
+                expression {
+                    return env.BRANCH_NAME == 'main'
+                }
+            }
             parallel {
                 stage('Build image (bookworm)') {
                     agent any

Ca permet de totalement skip les étapes de build quand on est pas dans main. Testé rapidement là https://jenkins.entrouvert.org/job/gitea/job/publik-functests/job/wip%252F94486-Ne-lancer-les-tests-que-sur-main-quand-on-est-dans-un-cron/ On voit les trous.

Et on a déjà options { disableConcurrentBuilds() } qui empêche d'avoir plus d'un build sur une même branche.

Le seul inconvénient c'est qu'on ne pourra plus tester le build d'image depuis une branche. Mais je me dis que ce n'est pas trop grave. "Tout" est dans devinst. Le peu qu'installe ce projet dans l'image ne devrait pas bouger souvent. Et si ça casse en de rares occasion, ce n'est pas bien grave.

L'avantage est qu'on a pas à gérer de lock dans le Makefile. Vu que c'est du code qui tourne aussi en local, j'aimerai autant qu'on s'en passe.

Opinion ?

Gael Pasgrimaud a écrit :

Ca permet de totalement skip les étapes de build quand on est pas dans main. Testé rapidement là https://jenkins.entrouvert.org/job/gitea/job/publik-functests/job/wip%252F94486-Ne-lancer-les-tests-que-sur-main-quand-on-est-dans-un-cron/ On voit les trous.

Le seul inconvénient c'est qu'on ne pourra plus tester le build d'image depuis une branche. Mais je me dis que ce n'est pas trop grave. "Tout" est dans devinst. Le peu qu'installe ce projet dans l'image ne devrait pas bouger souvent. Et si ça casse en de rares occasion, ce n'est pas bien grave.

Comme autres inconvénients que je vois, c'est que si l'image n'existe pas/plus :

• il faut relancer le build par la branche main
• des tests qui seraient lancés dans une branche partirons en erreur tant que l'image ne sera pas prête (au lieu d'attendre 900s max sur le flock avant de partir en erreur)

L'avantage est qu'on a pas à gérer de lock dans le Makefile. Vu que c'est du code qui tourne aussi en local, j'aimerai autant qu'on s'en passe.

De mon côté je ne vois pas de soucis au flock en local, sauf qu'a priori ils n'a pas une grande utilité (protéger contre une erreur de manip improbable ?) : je pense qu'on peut modifier la PR pour que seul la target jenkins_build utilise flock et remettre une target build qui n'utilise pas de flock.