PR Docker et le workflow Github

Suite du sujet (fermé?)

La 2e PR est ready to merge :slight_smile:
Aussi, j’ai vu plusieurs sujets sur un bug du synology pas compatible avec l’image Jeedom sous bullseye

une solution serait de continuer à produire l’image docker sous buster avec un tag spécifique, permettant aux utilisateurs concernés de l’utilise à la place de latest ( docker run jeedom/jeeom:buster par exemple)
Je propose de faire ça dans un prochain PR, il faut modifier le workflow pour créer un tag supplémentaire. ok ?

Salut pifou,
Merci pour maintenir ce qu’il faut pour mettre Jeedom sous docker.
Je l’essaye justement depuis peu.
Bon courage.

Bonjour
Si tu y arrives je suis preneur oui je n’y comprends pas grand chose au workflow github

C’est fait

J’ai fermé la précédente PR du coup, celle-ci la remplace.

Je me demandais comment on gère les PR ouvertes, si faut les mettre à jour ou pas, sinon ça risque de diverger avec le upstream non ? Mais dans ce cas les commit de merge s’accumulent ça devient vite le bazar. C’est un peu pour ça que j’ai refait une nouvelle PR avec 1 seul commit propre (pas réussi à faire des squash sur l’ancienne PR)

1 « J'aime »

Super merci et oui un nouveau pr c’est plus simple je trouve. J’ai validé le pr on va laisser tourner le workflow pour voir ce que ça donne

Ok, il n’y a plus de workflow automatique quotidien. il se déclenche quand tu merge sur beta ou V4-stable, ou sinon tu peux le déclencher manuellement sur alpha si tu veux le tester.

Voilà normalement je l’ai relancé

1 « J'aime »

Je ne sais pas ce que tu a relancé, mais je ne trouve pas les logs. A priori il s’est rien passé, pas de nouveaux tags sur le docker-hub non plus. Il y a toujours les workflow scheduled par contre, je ne sais pas s’ils sont lancé à partir de la branche V4-stable ou beta, ou peut être les 2. Il faut donc peut-être aussi pousser la modif dans la branche par défaut, je suppose V4-stable pour que ça soit pris en compte… Tu l’a bien relancé sur la branche alpha ?

Ben oui pourtant bien l’alpha je viens de relancer la. C’est quand même pas super clair les workflow github je trouve.

C’est bon, cette fois le workflow manuel s’est bien lancé :slight_smile: il a marché, en tout cas pas d’erreurs dans les logs. Ce que je ne comprends pas c’est que, côté docker hub, je ne vois pas de nouveaux tags.

#18 exporting to image
#18 pushing layers 25.1s done
#18 pushing manifest for docker.io/***/jeedom:4.4-buster
#18 pushing manifest for docker.io/***/jeedom:4.4-buster 0.7s done
#18 DONE 136.6s

Je m’attendrais à trouver maintenant une image jeedom/jeedom:4.4-buster … Or elle n’y est pas. ça met peut être du temps (ça fait déjà 24h) ou bien alors il faut une action manuelle, … J’ai demandé un support sur Docker pour voir.

Par expérience ça prends normalement que quelques minutes 1h max donc c’est bizarre surtout si il a bien push

Ok j’ai trouvé, le workflow a bien push mais pas au bon endroit:
https://hub.docker.com/r/zoic21/jeedom/tags

Du coup tu peux remplacer les credentials DOCKER_HUB_USERNAME et DOCKER_HUB_ACCESS_TOKEN de zoic21 par ceux de jeedom puis relancer le workflow stp ?

Ou alors, si c’est différent par branches, il suffit de push / merge le commit sur les branches beta et V4-stable, après tout, c’est validé maintenant :slight_smile:

Ben c’est le meme compte… En gros mon compte (zoic21) a accès a l’organisation docker hub jeedom.

Je pense il faudrait la core/docker-image-latest.yml at alpha · jeedom/core · GitHub modifier par « jeedom/jeedom:${{ env.JEEDOM_SHORT_VERSION}}-buster » pour le forcer a pousser sur l’organisation jeedom.

Ok autant pour moi, je n’avais pas capté ce détail… moi je push directement sur le repo qui a le même nom que mon compte :smiley:
J’ai corrigé le truc, je me suis laissé une variable secret optionnel et je force le nom du repo = jeedom

Top merci je viens de faire le merge et de lancer le workflow, on verra dans quelques minutes/heures.

Merci en tout cas pour tout ton travails la dessus c’est une partie que je maitrise vraiment pas…

oui ça marche c’est cool :slight_smile:

J’ai bien commenté dans le workflow, mais n’hésites pas à demander s’il y a des pb ou évolutions à ajouter! Bon, ça marche sur alpha, ça passera sur beta quand vous mergerez le tout, par contre ça serait possible de passer cette modif sur la v4- stable aussi ? Peut être je te fais un cherry-pick + PR sur v4-stable ?
Histoire de générer les images ausi pour la v4.3 et 4.3-buster

Fais le sur la beta, et je ferais le merge depuis la beta (pour le moment la beta c’est encore 4.3 donc c’est possible).

C’est cool si on a des tags par version quand meme.

Ha bon mais dans ce cas, on va générer une image avec le tag 4.3 mais avec le code de la beta c’est un peu confusing non ?

Effectivement mais ca va faire pareil quand je vais monter l’alpha en beta non sauf avec les tags 4.4 ?

1 « J'aime »

oui, pareil, ça prend le numéro de version du fichier core/config/version et ça le colle dans le tag.

Donc oui la branche beta actuelle est encore en 4.3 et c’est pas encore la version beta en fait ? beta = 4.3 plus les hotfix en cours au final ?