野良 Scrapbox アプリ - Vuetify 2 の v-data-table への移行

野良 Scrapbox アプリのページ一覧画面では Vuetify の Data table component を使っています。

f:id:kondoumh:20191027100402p:plain

Vuetify は v1 → v2 でかなり breaking change が入りました。

https://github.com/vuetifyjs/vuetify/releases/tag/v2.0.0#user-content-upgrade-guide

数ヶ月 v1 のまま放置してましたが、やっとv2 に移行しました。

Apply vuetify 2 v-data-table · kondoumh/sbe@5fbaf09 · GitHub

  • :pagination 属性が廃止され、:options で指定するようになった
  • v-pagination コンポーネント(上部に配置してるページャー部品) との接続方法が変わった
  • ヘッダーのテンプレートが列単位の指定に
  • Vuetify モジュールの初期化方法が変わった
  • サーバーサイドのデータ件数が :total-items から :server-items-length
  • サーバーにリクエストを投げる時は、options の状態を取得してパラメータを組み立てるスタイルに
  • CSS のクラス名が table.v-table から .vdata-table に

と、色々変わってました。

Vue 本体も 3系では色々と変わるみたいですが。

github.com

ところで、Electron は 7.0.0 で OS の外観モード(ダーク、ライト)に合わせてモードが変わるようになりました。

Electron 7.0.0 | Electron Blog

ということで Electron 7.0.0 へのアップデートに合わせて、一覧画面でも OS がダークモードだったら Dark theme を適用するようにしてみました。

f:id:kondoumh:20191027093021p:plain

Release v1.2.0 · kondoumh/sbe · GitHub

Theia (VS Code ベース Web IDE) as a Service の Gitpod を使う

最近になって Gitpod を知りました。

www.gitpod.io

知ったきっかけは VS Code オンライン版の code-server を VPS などで自前で構築している人たちの記事を読んだことでした。

github.com

code-server は Digital Ocean の Droplet を使ってワンクリックでデプロイできるようになっていますが、ホスティングサービスは見当たりません*1。必要時にだけ利用できるセキュアな環境を構築するのは結構手間暇がかかるのでプロバイダーに任せたいと思いました。

VS Code ベースのオンライン IDE である Theia というのがあります。

theia-ide.org

Theia 自体をホスティングしているのが Gitpod です。 1ヶ月100時間まで無料で使えます(公開リポジトリのみ)。たまに個人開発で使う程度なら十分でしょう。

www.gitpod.io

ちなみに Theia は Eclipse Che 7 でも使われていました。

blog.kondoumh.com

Gitpod には Chrome 拡張が提供されていています。

chrome.google.com

この拡張をインストールすると GitHub リポジトリの Clone or download の右側に Gitpod ボタンが追加されるのでこれをポチっとするだけで、専用のワークスペースに展開してくれます。ラク過ぎてクラクラします。

f:id:kondoumh:20191020222609p:plain

ワークスペースにはちょっと前の世代の VS Code が再現されています。コード補完やターミナルなども問題なく使えます。

f:id:kondoumh:20191022021504p:plain

エディタの設定はアカウント共通のようですが、.theia/setting.json にワークスペース毎の設定を書くこともできます。

Java / Go / Python / C / C++ / Rust などの環境はインテグレートされているため、そのまま開発に入れる感じですが、Vue など特定フレームワーク用の VS Code 拡張は未導入なため vue ファイルのシンタックスハイライトなどが効いてません。

f:id:kondoumh:20191020232429p:plain

現時点では VS Code のように Marketplace を検索して拡張を追加することはできませんが、Marketplace をブラウザで開いて、Download Extension リンクから vsix 形式のファイルを取得してアップロードすればインストールができます。

f:id:kondoumh:20191020232554p:plain

Vue 用の拡張 vetur の vsix 形式のファイルをドラッグ&ドロップしてアップロード・インストールしてみました。

f:id:kondoumh:20191020232451p:plain

ちゃんと有効化されました。

f:id:kondoumh:20191020232507p:plain

シンタックスハイライトも効いてます。

f:id:kondoumh:20191020232525p:plain

VS Code 拡張を追加すると、プロジェクトルートに .gitpod.yml が追加され以下のような情報が出力されていました。

vscode:
  extensions:
    - octref.vetur@0.22.4:F5isQXjXpm5hcM6ONMslcA==

このファイルをコミットしておけば、新たにワークスペースを作り直した時も拡張がインストールされるのでしょう。

ところで、Vue などの Web アプリはターミナルで $ npm run serve で起動してプレビューすることができます*2

初期状態では、プレビューのブラウザに Invalid Host header というエラーが出てしまいます。そこで、vue.config.js に devServer の設定を追加します。

module.exports = {
    :
  devServer: {
    disableHostCheck: true
  }
}

これで正常にレンダリングされるようになりました。別ウィンドウに出せば、Chrome の DevTools も使えます。

f:id:kondoumh:20191022023059p:plain

VS Code は OS 機能との連携も重要で、ターミナルで使う CLI や Git CUI の Tig なども使いたくなります。NPM / pip / go module など言語のパッケージ管理システムでインストールするものはいいのですが、そうでないものはイメージのビルドプロセスに組み込むしかありません。

Gitpod は文字通り Kubernetes クラスターに配備される Pod なのでコンテナイメージのカスタマイズも可能です。

Gitpod - Docker Image

先ほどの .gitpod.yml に public なイメージを指定するか、独自 Dockerfile を指定することができます。

image:
  file: .gitpod.dockerfile

.gitpod.dockerfile では apt-get で Tig をインストールするよう記述してみました。

FROM gitpod/workspace-full:latest

USER root

RUN apt-get update && \
    apt-get install tig

これをリポジトリに commit / push してワークスペースを作り直すとイメージビルドが始まります。

f:id:kondoumh:20191022013641p:plain

エラーがなければビルドが終わりワークスペースが起動します。ターミナルで tig もちゃんと起動します。

f:id:kondoumh:20191022014402p:plain

2回目以降はビルドしたイメージが使われるので、通常のワークスペースと同じ時間で起動します。プロジェクト毎にイメージをビルドするのが面倒な場合、Docker Hub にイメージを置いて使うとよいでしょう*3。あるいは代替となる VS Code 拡張を探すのもありかもしれません。

ちなみに .gitpod.yml には、コンテナ起動時に実行したい task を登録しておくことができます。Gitpod で起動された環境のタイムゾーンは UTC になっており、git commit した時のタイムスタンプが日本とはずれたりします。そこで以下のようにタイムゾーンを設定するコマンドを実行するようにしてみました。

tasks:
  - command: export TZ="Asia/Tokyo"

以上、ざっくり GItpod を使ってみました。拡張がワークスペース単位だったりしてデスクトップで最新の VS Code を使っている感じとはちょっと違いますが、Eclipse Che や CodeSandbox よりも VS Code 成分高めだし、このレベルの開発環境がほぼ制限なく利用できるというのはすごいです。

現時点では PWA に対応していないのでデスクトップアプリのように使うには Electron などを使うことになります。あと、iPadOS の Safari でもちゃんと使えたということも記しておきます。

f:id:kondoumh:20191022102359p:plain

*1:以前は Coder.com でホスティングされていた模様です。

*2:ローカルサーバーを起動した時にポートを expose するかというポップアップが出ます。

*3:イメージのメンテナンスが必要になりますが。

iPadOS on iPad Air 2nd gen

iPadOS を2014年発売の iPad Air 2 にインストールして使っています。

デスクトップが広く使えるようになり、ウィジェットも置けるようになりました。

f:id:kondoumh:20191014073955p:plain

日没後はダークテーマになるように設定してみました。

f:id:kondoumh:20191014074021p:plain

ファイルアプリで、ローカルリモート問わずファイルの圧縮と伸長が可能になり、ファイルのコピーもわりと簡単に。Dropbox のファイルを複数圧縮してクラウドストレージ非対応アプリのフォルダに展開しアプリから開くといったことが容易になりました。

f:id:kondoumh:20191008215221p:plain

スライドオーバーアプリの切り替えが簡単になったのもよい感じです。

f:id:kondoumh:20191014114250p:plain

テキストのコピペ、Undo / Redo の3本指アクションはブラウザのテキストエリアでも有効なので、ブログなどの文章を書く時にも使えます。

開発環境としてはデスクトップクラスになったという Safari による Web IDE の使い勝手が気になるところです。

CodeSandbox はVS Code とインテグレートされて進化しています。

codesandbox.io

残念ながら Safari では画面が表示されませんでした。iOS12 では使えていたのですが・・・。Chrome では 今のところ使えています。

f:id:kondoumh:20191014084339p:plain

ただし PC ブラウザ版と設定項目が異なり、iOS モードで動作している模様です。サードパーティに Safari と同等の WebKit が提供されると Chrome でも動作しなくなるかもしれません。

同じく VS Code ベースの Eclipse Che 7

blog.kondoumh.com

こちらは認証トークンの処理でエラーになって Safari でも Chrome でも起動しませんでした。ちなみに AWS Cloud 9 も 3rd party cookie が無効化されているために Safari でも Chrome でも起動しません。iOS ファミリの方針のようなので致し方ないところでしょう。

ということで、主要な Cloud IDE の利用は当面期待できない感じで Safari に関しては期待はずれでした。したがってリモートマシンに SSH 接続する使い方が主体となります。

最近ユーザが増えているらしい Blink Shell を買ってみました。AWS や Google Cloud の VPS 使うときに Prompt だと UI で接続先指定するのがちょっとめんどくさいので、コマンドヒストリが使える Blink は便利です。まだ使ってないけど Mosh にも対応しているので接続の維持もしてくれそうです。

www.blink.sh

ベータテスト中の iSH Shell も完成度が上がってきています。Android の Termux とまでは行かないけど Alpine Linux のサブセットが動きます。

ish.app

Git も使えてシェルスクリプトも書けるので、ローカルでできることが増えます。Python も書けます*1

f:id:kondoumh:20191014132147p:plain

ただ Emacs は起動が遅くバックグラウンドに回ったアプリはリサイクルされてしまう *2 ので Vim を使うのが現実的です。

以上のように、iPadOS での開発はターミナル頼りという現状です。開発端末として使うよりも Catalina を導入した MacBook のコンパニオンとして、テザリング + サブディスプレイに使うのが正しい気がします*3

iPadOS 自体は iPad Air 2 でもちゃんと動くし、当面 iPad の買い替えは見送るつもりです。

*1:残念ながら Go は MMX Support が必要なので iPad のプロセッサでは起動しません。

*2:Termux は頑張って常駐します。

*3:Catalina にアップデートしたら試してみたいと思います。

OpenShift.io にホストされた Eclipse Che 7 (ほぼ VS Code & Remote Containers)

Cloud IDE は AWS Cloud 9 や CodeSandbox を時々使っています。

blog.kondoumh.com

blog.kondoumh.com

去年の初め頃、各種 Cloud IDE を比較してました。

blog.kondoumh.com

その後 Eclipse Che をホストしていた Codenvy は Red Hat に買収されてからは更新されていないようです。Codeanywhere も無料枠が無くなっていました。

そして先日、Eclipse Che 7 がリリースされました。 Kubernetes と OpenShift で稼働すること、VS Code ベースの Web IDE である Theia に移行したというのがメインのトピックとなっています。

che.eclipse.org

実はリニューアル前の Eclipse Che は仕事でかなり触っていて、独自のプラグインなどを作成したりしたので馴染みがあります。その時は GWT で IDE 内のウィジェットを作る必要がありました。 Web UI なのに Java で書いてヘビーなビルドパイプラインを実行する必要がありました。Theia ではそのあたりもモダンになっていることでしょう。

Red Hat は OpenShift.io で Che をホスティングしており、Red Hat Developer にサインアップすれば利用することができます。

developers.redhat.com

RHEL の開発者ライセンスやナレッジベースが使えるので入っても損はなさそうです。

https://che.openshift.io/

このサイトを開くとローディングが開始されます。途中 Red Hat Developer へのログインを促されます。

f:id:kondoumh:20191010230443p:plain

しばらく待つと Che のダッシュボードが開き、Workspace 作成画面になります。

f:id:kondoumh:20191010232704p:plain

この UI は Codenvy と変わっていませんが、利用できる Stack (Workspace のテンプレート) に .NET Core / Go / Python 3.6 / Spring Boot などが追加され、現在主流の言語・フレームワークをカバーしています。

f:id:kondoumh:20191011000522p:plain

Go の環境を作ってみます。Stack を選んで CREATE & OPEN ボタンを押すと構築が開始されます。

f:id:kondoumh:20191010233614p:plain

Docker コンテナのイメージがビルドされ起動されます。

f:id:kondoumh:20191010233656p:plain

準備ができると、Theia ベースのワークスペースが現れます。ほぼ、VS Codeですね。

f:id:kondoumh:20191010233855p:plain

メニューからターミナルを開くと、コンテナにアタッチした bash が起動します。

user というユーザでログインしており go の環境も設定済みです。

f:id:kondoumh:20191010235710p:plain

もちろん git clone でリモートのリポジトリを取得して開発できます。

VS Code と同様 LSP ベースのコード補完も有効です。

f:id:kondoumh:20191011000213p:plain

VS Code の Remote Containers の環境がブラウザ内で使えるような感覚ですね。

blog.kondoumh.com

Workspace の設定で、プラグインの追加や Editor の切り替えもできます。

f:id:kondoumh:20191011001537p:plain

CodeSandbox と違ってフロントエンドだけではなくフルスタックの開発も可能です。現時点では PWA 対応はされていませんが、今のところ無償のようですし Chrome が動けば使えるということで実用性は高いと思います。

野良 Scrapbox アプリ - ブラウザで開いたページを URL Scheme 経由で開く

Scrapbox を ブラウザで開いていてから「このページ sbe で開きたいなあ」ということがよくあります。

もともと sbe には URL をペーストして新規タブでページを開く機能はありますが、やはり手動はめんどくさいものです。

Electron にはシステムの URL Scheme で開かれるアプリとして自分自身を指定できる機能があります。

electronjs.org

この機能と bookmarklet などを組み合わせるとやりたいことが実現できそうです。

アプリの main プロセスで、sbe:// の形式での URL が発行されたときに呼び出されるよう setAsDefaultProtocolClient("sbe") のように指定した上で、open-url イベントを受け取り URL を取り出してrenderer プロセスに通知する処理を追加。

  :
  app.setAsDefaultProtocolClient("sbe");
  :
  app.on("open-url", (event, url) => {
    mainWindow.webContents.send("openUrlScheme", url.replace("sbe://", ""));
  });  

renderer プロセスでは指定 URL でページのタブを作成する処理を追加すれば良いはずです。

  :
  ipcRenderer.on("openUrlScheme", (event, url) => {
    tabGroup.openUrl(url);
  });
  :

ブラウザで URL の先頭に sbe:// を付けると確認ダイアログが出ます。

f:id:kondoumh:20191007195755p:plain

sbe.app を開く を選択すると無事に sbe 側のタブが開きました。

f:id:kondoumh:20191007200258p:plain

Windows の場合は、アプリへのコマンドライン引数として入ってきますので、main プロセスで引数の解析をして sbe:// とマッチするパターンから URL を取り出すようにします。

ブラウザに、今見ているページを sbe で開くための下記のような bookmarklet を追加してみました。

javascript:(function(){location.href=`sbe://${window.top.location.href}`})();

一応、期待通りの動作をします。bookmarklet だとマウス操作が必要になってしまうので、ショートカットキーも登録できる Surfingkeys などの拡張を使うと便利です。

chrome.google.com

ということで、URL Scheme 対応版をリリース。このバージョンから配布形式がインストーラーになってます。

Release v1.1.0 · kondoumh/sbe · GitHub

Minikube を macOS (HyperKit) | Windows (Hyper-V) で使う

Minikube は VirtualBox / VMware の VM をノードにして使うケースが多いと思いますが、macOS の Hyperkit や Linux の KVM、そして Windows の Hyper-V などホスト OS の HyperVisor による VM を使うことで、軽量で実行性能の高いノードで環境を構築することができます。

macOS に HpyerKit に特化した Minikube 環境を構築してみました。

hyperkit | minikube

すでに Docker Desktop を導入していたので、HyperKit は入っていると思っていたのですが、minikube start してみるとエラーが出たので brew でインストールしました*1

$ brew install hyperkit

minikube と docker-machine-driver-hyperkit (HyperKit の VM 上の Docker ドライバ) はバージョンを合わせられるよう GitHub の Releases からダウンロードして導入。

Releases · kubernetes/minikube · GitHub

$ curl -Lo minikube https://github.com/kubernetes/minikube/releases/download/v1.4.0/minikube-darwin-amd64
$ chmod u+x minikube
$ mv minikube /usr/local/bin/

$ curl -LO https://github.com/kubernetes/minikube/releases/download/v1.4.0/docker-machine-driver-hyperkit
chmod u+x docker-machine-driver-hyperkit
$ mv docker-machine-driver-hyperkit /usr/local/bin/

Minikube のデフォルト値を設定して、VM Driver として HpyerKit を利用するようにします。その他、仮想マシンの CPU 数やメモリ量なども設定しておきます。

$ minikube config set memory 4096
$ minikube config set cpus 2
$ minikube config set vm-driver hyperkit

$ minikube config view
- cpus: 2
- memory: 4096
- vm-driver: hyperkit

kubernetes のバージョンもオプションの --kubernetes-version で指定したり、config に設定しておくことが可能です。

クラスターを構築して起動します。デフォルトでは minikube という名前のクラスターを作成します。

 $ minikube start
😄  minikube v1.4.0 on Darwin 10.14.6
💾  Downloading driver docker-machine-driver-hyperkit:
    > docker-machine-driver-hyperkit.sha256: 65 B / 65 B [---] 100.00% ? p/s 0s
    > docker-machine-driver-hyperkit: 28.85 MiB / 28.85 MiB  100.00% 4.88 MiB p
🔑  The 'hyperkit' driver requires elevated permissions. The following commands will be executed:

    $ sudo chown root:wheel /Users/masa/.minikube/bin/docker-machine-driver-hyperkit 
    $ sudo chmod u+s /Users/masa/.minikube/bin/docker-machine-driver-hyperkit 


🔥  Creating hyperkit VM (CPUs=2, Memory=4096MB, Disk=20000MB) ...
🐳  Preparing Kubernetes v1.16.0 on Docker 18.09.9 ...
💾  Downloading kubelet v1.16.0
💾  Downloading kubeadm v1.16.0
🚜  Pulling images ...
🚀  Launching Kubernetes ... 
⌛  Waiting for: apiserver proxy etcd scheduler controller dns
🏄  Done! kubectl is now configured to use "minikube"

数分で起動し、kubectl の context が minikube にスイッチされます。

$ kubectl config get-contexts
CURRENT   NAME                 CLUSTER          AUTHINFO         NAMESPACE
          docker-desktop       docker-desktop   docker-desktop   
*         minikube             minikube         minikube         

namespace kube-system で動作している Pod を見てみると通常は、systemd でサービス起動している etcd / kube-api-server / kube-scheduler などが、-minikube という suffix 付きの Pod として起動していることがわかります。

$ kubectl get pod -n kube-system
NAME                               READY   STATUS    RESTARTS   AGE
coredns-5644d7b6d9-ghrbq           1/1     Running   0          8m56s
coredns-5644d7b6d9-gj8s9           1/1     Running   0          8m56s
etcd-minikube                      1/1     Running   0          8m9s
kube-addon-manager-minikube        1/1     Running   0          7m56s
kube-apiserver-minikube            1/1     Running   0          7m46s
kube-controller-manager-minikube   1/1     Running   0          7m42s
kube-proxy-9mtqh                   1/1     Running   0          8m56s
kube-scheduler-minikube            1/1     Running   0          8m3s
storage-provisioner                1/1     Running   0          8m52s

アクティビティモニタをみると HyperKit が 3GB ちょっとメモリを使用しており、config に指定した 4GBは下回っています。

f:id:kondoumh:20191005085717p:plain

使わないときは、クラスターを停止しておくことができます。

$ minikube stop
✋  Stopping "minikube" in hyperkit ...
🛑  "minikube" stopped.

これで HyperKit のプロセスは消滅します。

kubectl の向き先を Docker Desktop の Kubernetes に切り替えるには config use を使います。

$ kubectl config use docker-desktop

もう少し簡潔なコマンドエイリアスを提供してくれる kubectx のようなツールもあります。

github.com

次に、Windows 10 (Hyper-V) 環境への導入です。

hyperv | minikube

PowerShell を管理者モードで起動し、Hyper-V を有効化します。

> Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All

kubectl と minikube はバイナリを取得して、パスの通ったフォルダに配置します。

https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-on-windows

Releases · kubernetes/minikube · GitHub

Windows 版はインストーラーもありますが、minikube-windows-amd64.exe をリネームして使えばよいでしょう。

Minikube の start / stop は管理者モードで実行する必要があります。PowerShell や cmd.exe を管理者モードで起動します*2。minikube config で vm-driver に hyperv を設定しておきます。

f:id:kondoumh:20191005125443p:plain

起動中にダイアログが出るため、PowerShell のメッセージがくずれてしまっていますが・・

起動してしまえば kubectl の実行は非管理者モードで可能です。git-bash などを使った方が作業は楽でしょう。

f:id:kondoumh:20191005125819p:plain

Minikube はシングルノードであるため Auto Scaling などの機能は使えませんし、いくつかのプロセスをデーモンではなく Pod としてエミュレートしたりしているため、本番環境相当のテストはできませんが、通常の開発用途としては十分な環境と言えるでしょう。

HyperVisor ベースの仮想化技術を使うことで別 OS を起動するオーバーヘッドなく高速・軽量なノードを使えること、Docker Desktop と違って Kubernetes のバージョンの切り替えが簡単なこと、Docker デーモンを常駐させなくても利用可能なことなどもメリットかと思います。

*1:Docker Desktop ではランタイムに持っていてシステムのバイナリは使っていないのでしょう。

*2:Preview 版の Windows Terminal で実行しています。

GitHub Package Registry に GitHub Actions から Docker イメージを push

GitHub Actions に続き GitHub Package Registry も僕のアカウントで使えるようになりました。

github.com

blog.kondoumh.com

この時は、コンテナをビルドして終わりでしたが Registry が使えるようになったので コンテナイメージを格納する処理を追加してみます。

事前にアクセストークンを取得して、リポジトリの Settings で Secret を追加しておきます。

f:id:kondoumh:20190928101638p:plain

ワークフロー定義。イメージビルド後に Package Registry (docker.pkg.github.com) にログイン、イメージを push する処理を追加。

jobs:
  package:

    runs-on: ubuntu-latest

    steps:
          :
  build-image:

    needs: package
    runs-on: ubuntu-latest
 
    steps:
    - uses: actions/checkout@v1
    - uses: actions/download-artifact@master
      with:
        name: sb-sample-service.jar
        path: ./target

    - name: Build and push Docker image
      run: |
        docker build . --file Dockerfile --tag docker.pkg.github.com/kondoumh/sb-sample-service/app:latest
        docker login docker.pkg.github.com -u kondoumh -p ${{ secrets.DOCKER_REGISTRY_TOKEN }}
        docker push docker.pkg.github.com/kondoumh/sb-sample-service/app:latest

実行すると push 成功 しました。

f:id:kondoumh:20190928101821p:plain

格納されたコンテナを pull してみます。

$ docker login docker.pkg.github.com -u kondoumh
Password: 
  :
Login Succeeded

$ docker pull docker.pkg.github.com/kondoumh/sb-sample-service/app:latest
1.0: Pulling from kondoumh/sb-sample-service/app
e7c96db7181b: Pull complete 
f910a506b6cb: Pull complete 
c2274a1a0e27: Pull complete 
87e0b7342010: Pull complete 
Digest: sha256:97f2da5372e9f659dbe976e245835a4cb082960b2b6aac96ca6e84cdc7305d5b
Status: Downloaded newer image for docker.pkg.github.com/kondoumh/sb-sample-service/app:latest


$ docker image ls
REPOSITORY                                             TAG                 IMAGE ID            CREATED             SIZE
docker.pkg.github.com/kondoumh/sb-sample-service/app   latest                 a9ed328094d5        31 minutes ago      138MB

大丈夫みたいです。

さて、上記ワークフローだと、Git のブランチ名やタグ名をイメージのタグ名に付与するような処理を書く必要があり、やや面倒です。探したらコンテナイメージのビルドとタグ付け、push までをやってくれる Action がありました。

github.com

Master ブランチでビルドした場合は latest タグをつけてくれるようです。これを使ってワークフローを書き直してみます。

   :
  build-image:

    needs: package
    runs-on: ubuntu-latest
 
    steps:
    - uses: actions/checkout@v1
    - uses: actions/download-artifact@master
      with:
        name: sb-sample-service.jar
        path: ./target

    - name: Build image and Publish to Registry
      uses: elgohr/Publish-Docker-Github-Action@master
      with:
        name: docker.pkg.github.com/kondoumh/sb-sample-service/app
        username: kondoumh
        password: ${{ secrets.DOCKER_REGISTRY_TOKEN }}
        registry: docker.pkg.github.com

run でコマンドを書くよりも行増えてますが、より宣言的なスタイルになっています。デフォルトだと docker.io に push しようとするので、registry パラメータで Package Registry の URL を指定する必要があります。

ログを見るとちゃんと latest タグをつけてくれています。

f:id:kondoumh:20190928102313p:plain

CI とレジストリを完全装備した GitHub、ソースコードだけでなく、ビルド成果物の生成と管理ができるようになってしまいました。