GitHub Actions が手動実行に対応してた

GitHub Actions にはずっと手動実行が提供されていなかったので repository_dispatch トリガーを使って GitHub API 経由で起動することでしのいでいました。この方法は Master ブランチにしか適用できないという制約がありました。

先月 workflow_dispatch という手動実行用のトリガー機能がリリースされてました。

github.blog

日本語ドキュメントへの反映はまだのようです。

https://docs.github.com/en/actions/reference/events-that-trigger-workflows#manual-events

トリガーとして workflow_dispatch を指定してワークフローを選択すると Run workflow というボタンが表示され手動実行が可能になります。repository_dispatch と違ってブランチを指定することができます。

on: 
  workflow_dispatch:

f:id:kondoumh:20200805170411p:plain

さらに Action を書く時に使用するメタデータ構文で、ワークフロー実行時の入力値を設定できます。

docs.github.com

docs.github.com

workflow_dispatch に inputs でログレベルやタグ名を指定するサンプルが紹介されています。

on: 
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'     
        required: true
        default: 'warning'
      tags:
        description: 'Test scenario tags'

実行時に入力フォームが生成され、入力値を設定できます。この例では logLevel は必須で、デフォルト値として warning が設定されます。

f:id:kondoumh:20200805172713p:plain

ワークフローの job では入力値を github.event から取得でき、${{ github.event.inputs.logLevel }} のように取り出すことができます。

Jenkins のパラメータ付きビルドのように使えそうです。

  • テストケース番号を指定してテスト結果の成果物ファイル名に埋め込む
  • 他リポジトリのブランチ・タグを指定して checkout してテストする

などなど、いろいろと使い道が考えられます。

workflow_dispatch はGitHub API 経由で呼ぶことも可能です。Web UI と同様ブランチ指定する refinputs を POST パラメータで指定できます。

https://docs.github.com/en/rest/reference/actions#create-a-workflow-dispatch-event

Windows で VS Code Remote SSH を使う時のエラー対応

Windows 10 で VS Code の Remote SSH でリモートマシンへの接続が失敗すると Could not establish connection to "xx". というエラーダイアログが出ます。

f:id:kondoumh:20200805092020p:plain

エラーの要因はいろいろありますが、VS Code の出力に

[09:22:02.936] > Bad owner or permissions on C:\\Users\\kondoh/.ssh/config
> 
[09:22:02.946] > プロセスが、存在しないパイプに書き込もうとしました。

のように Bad owner or permissions on .../.ssh/config というメッセージが出る場合は config ファイルのパーミッションが問題があります。Remote SSH の Config File はデフォルトで %USERPROFILE%\.ssh\config になっていて、同ファイルのパーミッションが 400 になっていない場合にこのエラーになるようです。.ssh はプライベートキーが格納されるディレクトリなので config ファイルのパスを変更する方法で回避してみました*1

VS Code が提示してくる設定ファイル Remote-SSH:Open Configuration File.. の選択肢には、C:\ProgramData\ssh\ssh_config があります。

f:id:kondoumh:20200805090825p:plain

C:\ProgramData\ssh\ssh_config を選択するとパーミッションエラーでファイルが作成できません。C:\ProgramData 配下にファイルを作るのは管理者権限が必要です。

そこで C:\Users\<user>\.ssh\config で設定した内容を C:\ProgramData\ssh\ssh_config にコピーします*2。その後 C:\Users\<user>\.ssh\config は削除します*3

これで、無事に VS Code Remote SSH でリモートのプロジェクトを開いて作業できるようになりました。

別の方法として、Remote-SSH:Open Configuration File..Settings specify a custom configuration file で Config File のパスを設定する方法もあります。ユーザプロファイル配下に Config File を作れば、UAC の許可は不要です。

f:id:kondoumh:20200805090003p:plain

この他、

  • 踏み台サーバ経由で接続する場合 ProxyCommand にフルパスを指定する必要がある
  • SSL 証明書 (pem ファイル) を使用する場合、これもユーザプロファイル配下に配置しないと Permissions for 'xxx' are too open. のようなエラーになる

など、色々とハマりポイントがあります。

*1:Git for Windows を使ってるとパーミッションを変更するのがちょっと面倒そうなので。

*2:コピー時に Windows の UAC のダイアログが出るので OK する必要があります

*3:C:\Users\.ssh\config の優先度が高いらしく削除しないと冒頭のエラーが出ます。

iPad Pro 11 (2018) デビュー

去年奥さん用に買った iPad Pro 11 (2018)。最近は全く使ってないとのことでしばらく借りることにしました*1

自分の Apple ID でログインして Face ID を登録。

画面オンにしたらすでに認証完了してます。眼鏡アリでもナシでも認証でき、部屋の照明点いてなくても OK、物理キーボードがつながっている場合キーを2回打つだけで作業に戻れる・・と体験がよいです。各アプリの認証時に顔パスで Keychain のパスワードが入るところも快適でした。

Magic Keyboard と Bluetooth ヘッドセットをペアリングして Slack, Zoom, YouTube, Twitter 用に使うことにしました。ほとんどラップトップの感覚ですが、Pencil の書き心地いいので手書きメモにも活用できそうです。

f:id:kondoumh:20200725092135j:plain

先日 Let's note と iPad Air2 に割当てたタスクは iPad Pro に統合できました。

blog.kondoumh.com

Air2 と違ってランドスケープでステレオになるところも動画視聴に適してます。画面もちょっと大きいですし。ちょうど YouTube Premium に入ったところなのでバックグラウンド再生も可能で快適です。あと YouTube の再生位置を Pencil で動かせるのが便利です。指だと難しかったんで。

MacBook Pro を Displayport で外部ディスプレイに繋がなくなったので、USB-C - Displayport ケーブルで接続できるようにしました。

YouTube や Amazon Prime Video を大きい画面で見てます。特に Amazon Prime Video のアプリは外部ディスプレイがあるとミラーリングではなく、外部ディスプレイには映像のみをフルスクリーンで、iPad 側にはコントローラーが表示されるので便利です。

Air2 は寝室用になりました。iPad が各部屋にあるのは便利ですね。

ということで2年落ちの iPad Pro*2使いはじめました。

しかし Pro も Air2 も Cellular モデルなのに、ここ数ヶ月全然外に持ち出すことなく、パケット捨ててるだけなので勿体ない・・。

*1:借りパクではありません。

*2:SoC は 2020 とほぼ変わらないらしいですが。

GitHub Actions のセルフホストランナーがサービスとして登録可能になってた

GitHub Acitons では Self-hosted runner を利用して、独自のビルド環境でワークフローを実行することができます。

docs.github.com

企業内のプロキシサーバ配下のマシンでも利用できるので、

  • CI のたびにソフトウェアのインストールをしなくてもよい*1
  • 社外に出せないライブラリを利用したビルドが可能
  • GItHub Actions Runner の使用制限を超えてビルドマシンのリソースを自前で用意できる

などのメリットがあります。仕事でも EC2 の Ubuntu AMI を使って Self-hosted runner を構築しています。

GitHub Actions の初期の頃から Self-hosted runner の機能は提供されていましたが、ユーザープロセスとして起動するため、ホストマシンに SSH 接続して runner.sh を起動する必要がありました。runner.sh & とかでバックグラウンドで起動するといつの間にかプロセスが死んでたりするし、tmux で起動して detouch しておくのも信頼性に乏しいし・・。Docker コンテナ化して常時起動している人のブログも発見しましたが Docker がらみの CI で DinD 問題が発生するし・・ということでターミナルを1つ専用に上げっぱなしにして使っていました*2

runner.sh は標準出力にジョブの成功・失敗のログを出力するので Web UI 見なくても結果がわかります。セルフアップデート機能もあり、アイドリング時に自身のバージョンを自動的にアップデートしているようでした。

少し前にドキュメントを眺めてたら、Self-hosted runner をサービスとして登録できるようになっていました。

docs.github.com

Mac / Windows / Linux いずれの runner でも登録可能で、それぞれ launchd / PowerShell / systemd を利用したサービス化が可能です。Mac では plist、Linux では serviced も利用可能なようです。

ドキュメントの手順通り Service 登録したところ、実行ユーザは従来通りの non-root ユーザ (Linux なら ubuntu ユーザ) なので、ワークフローやシェルスクリプトには変更不要でした。

Terminal で見ていたログも、Linux では journalctl を使って runner のログをウォッチできます*3

$ sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f

docs.github.com

これで Self-hosted runner の運用がかなり楽になりました。

*1:ただし immutable なクリーン環境でのテストにならないというデメリットもあります。

*2:SSH セッション切れてもプロセスは残っているようでしたが。

*3:Windows では PowerShell でイベントログを見ることになります。

VS Code で Jupyter Notebook を使う

VS Code + Microsoft の Python 拡張だけで Jupyter Notebook が使えるのを知りました。

code.visualstudio.com

コマンドパレットから Notebook を新規作成できます。

f:id:kondoumh:20200723135306p:plain

あらかじめ Anaconda などで環境を構築するようガイドされています。とりあえず venv で環境を作りました。

% python3 -m venv jupyter_local
source jupyter_local/bin/activate
(jupyter_local) %

Notebook を開くとガチャガチャっとセルがレンダリングされ Jupyter や IPython などがインストールされてローカルに Jupyter Server が起動されます。Kernel が事前作成した環境で起動され Idle 状態になれば OK です。

f:id:kondoumh:20200723171219p:plain

セルにコードを入力して実行できることを確認。

f:id:kondoumh:20200723162533p:plain

venv にライブラリを pip install すればセルで使えます。

f:id:kondoumh:20200723162831p:plain

workspace のテーマを Light 系にすると Jupyter っぽさが増します。

f:id:kondoumh:20200724104826p:plain

使用できる Kernel は Python に限定されますが VS Code だけで手軽に Notebook が使えるのは便利だと思います。コード補完も効きますし。この他リモートの Jupyter Server に接続する機能もあります。.py ファイルにエクスポートすればデバッグも可能なようです。

Work from Home 環境 (PC リニューアルしたい)

テレワークではリモートデスクトップで客先マシンに接続して作業をしていて、自宅マシンにはさほど性能が要求されてませんでした。最近社内アプリ開発に関与するようになり Kubernetes ベースの開発環境を構築したら MacBook Pro 13 Early 2015 のスペック不足が顕著になりました。メモリ(16GB)はもちろん Intel Haswell 世代の Dual Core CPU が弱いです。

取り急ぎ、いろんなタスクを手持ちのマシンに割り振りました。

  • MacBook Pro 2015 (第4世代 Corei 7 / 16GB RAM)
    • Docker Desktop (Kubernetes enabled), VS Code, Chrome
  • Let's note CF-SZ6 (第7世代 Core i5 / 8GB RAM)
    • Slack, Scrapbox, Twitter
  • iPad Air2
    • Zoom, YouTube, etc.

Electron アプリのリソース使用量もばかにならないため MacBook では極力起動しないようにしました。iPad はデスク横にマウントしっぱなしです。

f:id:kondoumh:20200723095621j:plain

2020.08.09 追記)

その後 iPad Pro 2018 を導入し、MacBook Pro は完全に 開発用のリモートマシンになりました。Let's note CF-SZ6 を作業用マシンにして VS Code Remote SSH と Windows Terminal で MacBook Pro に接続してます。

  • MacBook Pro 2015 (第4世代 Corei 7 / 16GB RAM)
    • Docker Desktop (Kubernetes enabled), 開発環境
  • Let's note CF-SZ6 (第7世代 Core i5 / 8GB RAM)
    • Chrome, VS Code, Windows Terminal, 自作 Electron アプリ
  • iPad Pro 2018
    • Zoom, YouTube, Slack etc.

ラップトップはクラムシェルで使ってサイドに置くようにして机の上が少しすっきり。

f:id:kondoumh:20200809164447j:plain

(追記終わり)

MacBook Pro 買った時は1台で全て賄えるのがいいと思っていました。

blog.kondoumh.com

在宅作業が長くなり、いろんなタスクをこなすことを考えるとこのスタイルもありかなあと思います。プロセス起動や切り替えによる CPU・メモリのスパイクも減らせますし。YouTube とか Twitter などがメイン画面を占有せず流し見できるのもよい気がします。

ところで Kubernetes 使う Cloud Native 世代の開発環境を構築するために PC をリニューアルしたくなってきました。

MacBook Pro 13 2020 よさそうだけど持ち歩くことがないなら割高に感じる。Mac mini はまだ Intel 第8世代でデスクトップ向け Processor 積んでない。利用アプリや開発環境構築の楽さではまだ macOS がいいんだけど・・。

PC 買うなら AMD Ryzen のコストパフォーマンスがいい。最低 6 Core (12 thread) 、メモリ32MB は欲しいところ。できれば 8 Core (16 thread) メモリ 64GB を狙いたい。しかしWindows 10 + WSL2 で yak shaving するのめんどくさいし Linux 専用機にする?・・いずれにしても発熱・騒音・電気代を考えると腰が引ける・・。

などなど悩み中です。

GitBook から HonKit に移行する

iEdit のユーザーズガイド

iedit.kondoumh.com

GitBook で作ってました。

blog.kondoumh.com

今年の2月に動作環境の文言を修正しようとして久々に更新した時 gitbook-cli が Deplicated になっているのに気付きました。

GitBook.com のホスティングサービス専用になって、OSS の方はメンテされなくなった模様です。

www.gitbook.com

ユーザーズガイドは GitHub Pages で公開していますが、今後 メンテされないとなると新規のドキュメントには使わない方がいいなあと思っていました。

最近 azu さんが GitBook を fork した HonKit という OSS の開発を開始されました。

github.com

自分はGitBook(legacy)の機能的にはある程度満足していたので、 主にコードベースの整理、TypeScript化、QやjQueryの依存を外すなど質的なメンテナンスが中心になる気がしています。

efcl.info

TypeScript 化や jQuery 依存の除去などは今後メンテナンスを続け、Contribute しやすくなるメリットがあると思います。

iEdit のドキュメントを HonKit でビルドしてアップデートしました。NPM 管理には移行していたので、gitbook-cli を honkit に置き換えて、script で使用するコマンドを gitbook -> honkit に変更するだけで移行完了。利用しているプラグインはそのまま動作しました。

  "devDependencies": {
-   "gitbook-cli": "^2.3.2"
+   "honkit": "^3.4.0"
  },
  "scripts": {
-   "serve": "gitbook serve",
-   "build": "gitbook build ./ ./docs"
+   "serve": "honkit serve",
+   "build": "honkit build ./ ./docs"
  },

HonKit を使えば、既存の GitBook 資産を Netlify や GitHub Pages などで安心してホスティングできるので、何より既存 GitBook ユーザには朗報ですね。