野良 Scrapbox アプリ - プロジェクトを選択してページ一覧を開く UI

野良 Scrapbox アプリのページ一覧は Scrapbox のプロジェクトページよりも素早く開いて見通しがいいのですが、開くには対象のプロジェクトのページを開いておく必要がありました。なので、まずプロジェクトのホームかプロジェクト内の任意のページを開いてからページ一覧を開くという2ステップが必要でした。また、複数プロジェクトのページを開いている場合はアクティブなタブのプロジェクトの一覧が開かれるという仕様にしているため、どのプロジェクトのページ一覧が開くのか直観的に分かりづらい問題がありました*1

そこで、プロジェクトのページを開くたびにプロジェクト名の履歴を残しておき、セレクトボックスから直接ページ一覧画面を開くことができる UI を追加しました。

favs や History と同じ感じのセレクトボックス。

f:id:kondoumh:20200924125227p:plain

一度開いたプロジェクトが列挙されてます。

f:id:kondoumh:20200924125246p:plain

選択したプロジェクトのページ一覧が表示されます。

f:id:kondoumh:20200924125301p:plain

ということで v2.0.0 リリース。

Release v2.0.0 · kondoumh/sbe · GitHub

*1:プロジェクトを1個だけ扱ってる場合はさほど気になりませんが。

GitHub CLI 1.0 がリリースされたので使ってみる

GitHub の CLI 1.0 がリリースされました。

github.blog

macOS だと brew でインストールできます。

% brew install gh
Updating Homebrew...
==> Auto-updated Homebrew!

==> Downloading https://homebrew.bintray.com/bottles/gh-1.0.0.catalina.bottle.ta
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/77b42bd6b610134ee3b40
  :
==> Summary
🍺  /usr/local/Cellar/gh/1.0.0: 60 files, 16.2MB

gh auth login で対話的に認証設定ができます。Personal Access Token を使って認証するようにしました。reporead:org へのアクセスを許可した Token を指定する必要があります。

% gh auth login
? What account do you want to log into? GitHub.com
- Logging into github.com
? How would you like to authenticate? Paste an authentication token

Tip: you can generate a Personal Access Token here https://github.com/settings/tokens
The minimum required scopes are 'repo' and 'read:org'.
? Paste your authentication token: ****************************************
? Choose default git protocol SSH
- gh config set -h github.com git_protocol ssh
✓ Configured git protocol
✓ Logged in as kondoumh

ドキュメントは以下。

cli.github.com

Core commands として gist, issue, pr, release, repo のサブコマンドが、Additional commands として上記の auth や config, help などの補助的なサブコマンドが提供されています。

CORE COMMANDS
  gist:       Create gists
  issue:      Manage issues
  pr:         Manage pull requests
  release:    Manage GitHub releases
  repo:       Create, clone, fork, and view repositories

ADDITIONAL COMMANDS
  alias:      Create command shortcuts
  api:        Make an authenticated GitHub API request
  auth:       Login, logout, and refresh your authentication
  completion: Generate shell completion scripts
  config:     Manage configuration for gh
  help:       Help about any command

ローカルに Clone したリポジトリのディレクトリに移動して、gh release を使うとリリース一覧 や個別のリリースの ChangeLog や Assets を見ることができます。

f:id:kondoumh:20200920190935p:plain

release listrelease view などの サブコマンドに --web (-w) フラグをつけると Web ブラウザで該当ページを開きます。

% gh release view v1.9.0 -w
Opening github.com/kondoumh/sbe/releases/tag/v1.9.0 in your browser.

repo サブコマンドでは、clone や create ができますし、repo view でテキストブラウザ的に Terminal で リポジトリの README を閲覧できます。

f:id:kondoumh:20200920194424p:plain

サブコマンドの使い方を調べるには gh help issue list のように help を挟めば usage がプリントされます。

% gh help issue list
List and filter issues in this repository

USAGE
  gh issue list [flags]

FLAGS
  -a, --assignee string    Filter by assignee
  -A, --author string      Filter by author
  -l, --label strings      Filter by labels
  -L, --limit int          Maximum number of issues to fetch (default 30)
      --mention string     Filter by mention
  -m, --milestone number   Filter by milestone number or `title`
  -s, --state string       Filter by state: {open|closed|all} (default "open")
  -w, --web                Open the browser to list the issue(s)

INHERITED FLAGS
      --help              Show help for command
  -R, --repo OWNER/REPO   Select another repository using the OWNER/REPO format

EXAMPLES
  $ gh issue list -l "help wanted"
  $ gh issue list -A monalisa
  $ gh issue list --web
  $ gh issue list --milestone 'MVP'

ここでは、list や view などの参照系コマンドだけしか示してませんが、issue や Release や PR などを create したり delete したりする更新系のコマンドも利用できます。GitHub のページで Chrome のタブがいっぱいになりがちなので、CLI と Web をうまく使い分けられると効率が上がりそうですし、自動化にも役立ちそうです。Actions のサブコマンドも提供されるとよいと思いました。

Additonal commands として api があります。GitHub API を最初から認証された状態で呼び出せます。

% gh api repos/kondoumh/sbe/releases

curl で呼び出すのに比べると https://api.github.com という固定の base url を省略できたり、認証トークンを ヘッダーに渡す手間が省けるのでこれも便利だと思います。

helmfile がステキになってた

helmfile は 複数の Helm Chart をまとめて Kubernetes cluster にデプロイするツールです。

github.com

Helm のラッパーとなっており、複数の Chart から構成されるアプリを効率よくデプロイ、更新できます。Helm Chart のインストール順というか依存関係の管理もできますし、デプロイ前後のフックでなにかの処理を実行したりすることも可能です。Helm と同様 Go Template が使えるので sed で置換したりが不要になります。

個人プロジェクトのようですが、開発は活発で contributer は 130人越えです。

Even though Helmfile is used in production environments across multiple organizations, it is still in its early stage of development, hence versioned 0.x.

とのことで 現在 v0.125.8。いいかげん v1.0 リリースしてもいい気ががします。

helmfile 便利なので自分も GitHub Actions で helmfile をセットアップする Action を作って公開してるほどです。

github.com

けっこう古いバージョンを使っていて最新を追ってなかったのですが、いつの間にか Helm Chart だけでなく Kustomize や Plain manifest のデプロイも対応してました(v0.118.0)。

Release v0.118.0: feat: GA of Kustomize and K8s manifests support (#1172) · roboll/helmfile · GitHub

Kustomize のアプリも plain manifest も local chart として扱えるので kubectl や kustomize コマンドを別途叩かなくてもよくなりました。

その少し前、namespace がなかったら作るという機能も追加されてました。

Release v0.113.0: Support for createNamespace (#1226) · roboll/helmfile · GitHub

デプロイ先の namespace は手順やシェルスクリプト内で別途作るので、作り忘れ、消し忘れが発生しやすい部分ですが、これで helmfile にお任せできるようになりました。

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 で外部ディスプレイに繋がなくなったので、iPad Pro を 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 でイベントログを見ることになります。