Kuby-core: Utiliser buildx

Hé!

Il est possible d'utiliser buildx dès maintenant, si vous le définissez comme constructeur par défaut .

Voici un exemple d'action Github qui utilise buildx et ses capacités de mise en cache : https://github.com/anycable/anycable_rails_demo/pull/25/files#diff -28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R28-R44

Voir aussi https://evilmartians.com/chronicles/kubing-rails-stressless-kubernetes-deployments-with-kuby#deploying-continuously-with-kuby-and-github-actions

Je cherchais juste quelque chose comme le drapeau --only , car j'avais du mal à configurer la mise en cache ! J'ai eu l'idée que je devais séparer les étendues pour chaque type de construction, comme je vois que vous l'avez fait ici.

Merci beaucoup pour les références pratiques 👍 Je suis maintenant pour voir si elles me permettent de franchir la ligne !

Il me manquait définitivement aussi la fonctionnalité de constructeur par défaut de setup-buildx-action ( install: true )

Cela semble fonctionner maintenant! Je viens de voir une création d'image d'application terminée en moins de 10 secondes. Il y a d'autres problèmes que j'ai maintenant, peut-être une régression que j'ai trouvée où RAILS_MASTER_KEY n'est pas exporté correctement, mais je vais aller lire la source pour le savoir maintenant.

Si j'utilise le install: true comme dans ce commit, alors la méthode build de lib/kuby/docker/cli.rb invoque buildx , et je peux passer des constructions buildx comme --cache-to après le -- pour les mettre dans le tableau *docker-args 👍 donc cela peut être fermé, sauf qu'il pourrait être agréable pour kuby-core de documenter comment il peut être utilisé avec buildx, ce n'est strictement pas le problème de kuby

Avec l'exemple dans :

https://github.com/kingdonb/kuby_test/commit/d74bf51e04253359b0d54aae7ddd6723ea6fd41d#diff -e2ad06bfd6b3aefc2d5f4fe8f60e0015b16947abc16764adef02e4339ac07a42R17-R20

Je peux utiliser buildx, donc ce problème peut être fermé.

C'est vraiment cool, merci d'avoir compris les trucs buildx ! J'avais l'impression que vous pouviez définir une variable d'environnement et que ce serait Just Work™, est-ce ce que fait cette action docker/setup-buildx-action@v1 ? Il semble que buildx soit fourni avec Docker Desktop et des versions plus récentes installées via des packages deb/rpm, je me demande donc si Kuby pourrait simplement l'utiliser par défaut. S'il est configurable via env var, peut-être que l'invocation docker buildx build n'est pas nécessaire ? Peut-être que Kuby peut le détecter et revenir à la normale docker build ?

Oui, c'est possible (et c'est ce que fait install: true dans l'action GitHub): https://docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default- constructeur

D'accord, si docker build n'est qu'un alias pour docker buildx , alors je ne vois pas la nécessité pour Kuby de faire quoi que ce soit de spécial. Il devrait appartenir à l'utilisateur de configurer le constructeur qu'il souhaite.