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、ソースコードだけでなく、ビルド成果物の生成と管理ができるようになってしまいました。

VS Code の Remote Containers で Java 12 開発環境を構築

以前 VS Code の Remote Development を試した時は VirtualBox の仮想マシンをターゲットに環境を作りました。

blog.kondoumh.com

Remote Development では Docker コンテナもターゲットマシンに使えます (Remote - Containers) 。

marketplace.visualstudio.com

特定の言語・フレームワークをインストールしたコンテナイメージを用意しておけば、面倒な環境構築をスキップして開発を開始できます。

前から気になっていた VS Code の Java 拡張の使い勝手も知りたいと思い、Java 12 環境を Docker - Containers で作ってみました。Docker Desktop for macOS を使用しています。

Java 環境用のフォルダを作成し、VS Code で開きます。

コマンドパレットで、Remote-Containers: Add Development Container Configuration Files を選択

f:id:kondoumh:20190921173515p:plain

選択メニューから Java 12 openjdk:12-jdk を選択

f:id:kondoumh:20190921173539p:plain

.devcontainer というフォルダが作成され、設定の JSON ファイルや Dockerfile が生成されます。ポップアップの Reopen in Container をクリック。

f:id:kondoumh:20190921173607p:plain

コンテナのビルドが始まります。

f:id:kondoumh:20190921173647p:plain

コンテナが起動されると、接続状態になります。

f:id:kondoumh:20190921173831p:plain

この状態で docker ps するとコンテナが起動していました。

$ docker ps
CONTAINER ID        IMAGE                                       COMMAND                  CREATED              STATUS              PORTS               NAMES
347c4633b941        vsc-java-a10e83bc1108453baed86ae69c6ee569   "/bin/sh -c 'echo Co…"   About a minute ago   Up About a minute                       ad

.devcontainer が配置されるフォルダはホストマシンにボリュームマウントされていますので、コンテナが破棄された後もファイルは残ります。

VS Code のターミナルを開いて、Java のバージョン情報や OS の情報を見てみます。

f:id:kondoumh:20190921180541p:plain

ちゃんと openjdk 12.0.2 がインストールされていて、OS は Oracle Linux Server 7.6 であることがわかります*1

コンテナ側にインストールされた Extension を確認すると、Java Extension Pack と Maven for Java はインストール済みになっていました。

f:id:kondoumh:20190921211358p:plain

フォルダを追加してコマンドパレットから Java: Create Java Project を実行します。

f:id:kondoumh:20190922001327p:plain

追加したフォルダを選択して OK を押します。

f:id:kondoumh:20190922001522p:plain

プロジェクト名を入れて Enter を打つと別ウィンドウが起動して、Java プロジェクトを開きます。このウィンドウもコンテナにアタッチされています。コンソールアプリなので、main 関数の上に表示されている Run をクリックすると実行されます。

f:id:kondoumh:20190922002139p:plain

ブレークポイントを追加して、Debug をクリックするとデバッグモードで実行しデバッグが可能です。

f:id:kondoumh:20190922002434p:plain

コード書いてみると補間はばっちり。import も自動追加されたりします。

f:id:kondoumh:20190922002737p:plain

ひとまず、Java 12 環境を作ってコードを書き始めることができました。

次は Spring Boot のプロジェクトを作ってみます。

コンテナには Maven CLI はインストールされていないようです。Dockerfile を見ると Maven や Gradle をインストールするスクリプトがコメントアウトされています。有効化してイメージをリビルドします。

f:id:kondoumh:20190921205804p:plain

コンテナが再起動され使えるようになりました。

f:id:kondoumh:20190921210550p:plain

コマンドパレットから Maven: Create Maven Project を実行します。

f:id:kondoumh:20190922004326p:plain

maven-archetype-quickstart を選択して、バージョンを選択

f:id:kondoumh:20190922005744p:plain

先ほどのフォルダを選択します。

f:id:kondoumh:20190922010105p:plain

archetype の処理が流れて groupId, artifactId などのプロンプトが出るので適当に入力していくとプロジェクトが作成されます。

f:id:kondoumh:20190922010153p:plain

生成されたプロジェクトの pom.xml を編集して、Spring Boot 用の設定をします。

  :
  <name>hello-springboot</name>

  <parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.1.8.RELEASE</version>
  </parent>
  :
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
    :

src/main/java/hello/App.java を編集してエンドポイントを追加、Boot アプリのエントリーポイントを追加します。

package hello;

import java.net.http.HttpRequest;

import org.springframework.boot.*;
import org.springframework.boot.autoconfigure.*;
import org.springframework.web.bind.annotation.*;

@RestController
@EnableAutoConfiguration
public class App 
{
    @RequestMapping(value = "/{name}", method = RequestMethod.GET)
    String hello(@PathVariable("name") String name) {
        return "Hello World! " + name + "\n";
    }

    public static void main(String[] args) {
        SpringApplication.run(App.class, args);
    }
}

ターミナルを分割し、片方で mvn spring-boot:run でアプリを起動、片方で curl でエントリーポイントにリクエストを送ってみます。

f:id:kondoumh:20190922012852p:plain

無事にレスポンスが取得できました。

実行しているコンテナは、VS Code のウィドウを閉じると破棄されます。

コンテナには vscode という non-root ユーザーも登録されていて、devcontainer.json の runArgs のコメントを解除すれば、vscode ユーザーで利用することも可能です。

{
    "name": "Java 12",
    "dockerFile": "Dockerfile",
          :
    "runArgs": [ "-u", "vscode" ],
          :
}

コンテナの設定については、公式ドキュメントが充実しています。

code.visualstudio.com

以上、Remote Containers の Java 開発環境、使い勝手としては IntelliJ IDEA や Eclipse に劣らない感じで、軽快な動作が素晴らしいです。Java 専用 IDE で便利プラグインを多用していると物足りないかもしれませんが。

コンテナを使うと開発準備も楽ですし、Dockerfile を配布すればメンバーの環境も統一できます。複数バージョンの JDK 混在させて切替えたりしなくてもよくなりますね。VS Code がコンテナの管理をかなり賢くやってくれるのが素敵です。

先日 .NET Core を試した時は、ローカル環境に .NET Core SDK をインストールしていました。

blog.kondoumh.com

これも C# (.NET Core) の Dev Container Configuration が提供されているのでこちらを使った方が手軽でした。

*1:RHEL 7.6 ベースです

Electron アプリのパッケージツールを electron-builder に移行

GitHub Actions で 野良 Scrapbox アプリの CI を 作った話の続きです。

blog.kondoumh.com

ほぼ同時ぐらいに azu さんが、同じテーマのブログを書かれてました。

efcl.info

僕のはビルドするところまででしたが、リリースまで実現されていて非常に参考になりました。特にパッケージツールとして使われている electron-builder が便利そうだったので早速移行することにしました。

www.npmjs.com

これまで electron-packager を使っていて electron-builder の存在は知ってたものの、試したことはありませんでした。各プラットフォームに対応した(完全に動作する)インストーラまで作ってくれます。

f:id:kondoumh:20190919214959p:plain

はなぢ出ました。

electron-packager の場合、インストーラを作成するには他の NPM パッケージとの併用が必要なので手をつけてませんでした。これでユーザーのインストール作業も簡単になります。

package.json にプラットフォーム毎の設定が書けるので npm script はプラットフォーム共通にできます。

  "build": {
    "productName": "sbe",
    "mac": {
      "icon": "icons/mac/sbe.icns"
    },
    "win": {
      "icon": "icons/win/sbe.ico"
    }
  },
  "scripts": {
    "start": "electron .",
    "pack": "electron-builder --dir",
    "dist": "electron-builder",
  },

インストーラ形式で生成されるため、各 OS のコマンドで成果物を zip 圧縮する必要もなくなりました。

おかげで GitHub Actions workflow の matrix.os による if expression も撲滅することができ、step も減らせて非常にスッキリしました。