Kuby-core: buildxの使用

おい！

デフォルトのビルダーとして設定すれば、今すぐbuildxを使用することができます。

次に、 buildxとそのキャッシュ機能を使用するGithubアクションの例を示します。

https://evilmartians.com/chronicles/kubing-rails-stressless-kubernetes-deployments-with-kuby#deploying-continuously-with-kuby-and-github-actionsも参照してください

キャッシュの設定に問題があったため、 --onlyフラグのようなものを探していました。 ここで行ったように、ビルドタイプごとにスコープを分離する必要があると思いました。

便利なリファレンスをありがとうございました👍私は今、彼らが私を一線を越えてくれるかどうかを確認するためにフォローしています！

setup-buildx-action（ install: true ）のデフォルトのビルダー機能も間違いなくありませんでした

今は動いているようです！ アプリのイメージのビルドが10秒未満で完了するのを見たところです。 私が今抱えている他の問題があります。おそらく、RAILS_MASTER_KEYが適切にエクスポートされていない場所で見つかったリグレッションですが、ソースを読んで今すぐ調べます。

このコミットのようにinstall: trueを使用すると、$＃$ 4 $＃$のbuildメソッドがbuildx lib/kuby/docker/cli.rbを呼び出し、 --cache-toのようなbuildx構造を渡すことができます。 -- $の後に$＃$を追加して、それらを*docker-args配列に入れます👍これを閉じることができます。ただし、kuby-coreがbuildxでの使用方法を文書化すると便利な場合があります。厳密にはクビーの問題ではありません

次の例を使用します。

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

buildxを使用できるので、この問題を解決できます。

これは本当にクールです、buildxのものを理解してくれてありがとう！ 私はあなたが環境変数を設定できるという印象を受けました、そしてそれはJustWork™でしょう、それはそのdocker/setup-buildx-action@v1アクションが何をしているのですか？ buildxにはDockerDesktopと、deb / rpmパッケージを介してインストールされた新しいバージョンが付属しているようです。したがって、Kubyは単にデフォルトでそれを使用できるのではないかと思います。 ただし、env varを介して構成できる場合は、 docker buildx buildを呼び出す必要はないのでしょうか。 たぶん、Kubyはそれを検出して、通常のdocker buildにフォールバックできますか？

はい、可能です（GitHubアクションのinstall: trueが行うことです）： https ：//docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default-ビルダー

了解しましたdocker buildがdocker buildxの単なるエイリアスである場合、Kubyが特別なことをする必要はないと思います。 必要なビルダーをセットアップするのはユーザーの責任です。