tmux 3.1c の window 分割線を ascii character にする

2020/10/30(Fri) に tmux 3.1c がリリースされました。

という事で、恒例の EastAsianAmbiguous を ascii に変更したバージョンを作成します。
過去の作業履歴は 3.1b や 3.0a や 2.9a  に、そもそもの問題についてはこの記事にまとめています。

環境

• OS: macOS Mojave 10.14.6
• tmux: 3.1c-border-ascii 7e7a923b7cd2e7cc8d2450e8a8e20838ded13298
• Homebrew: 2.5.8-118-g2ac5cff
• Homebrew/homebrew-core (git revision ce1b1; last commit 2020-11-06)
• Font: Ricty 4.1.1

インストール方法

• $ brew install --HEAD atton/customs/tmux

でインストールできます。

今回の作業

 3.1b と 3.1c の違いはほぼ無いようなものなので、 cherry-pick で対応できました。

PS4 の Prime Video の「次に観る」リストから消した作品を再度表示させる

私は Prime Video を観る際、大体 Play Station 4 を使っています。

Prime Video は「次に観る」というリストが視聴履歴から自動的に作成される為、放送中の作品を追うのに便利です。

観終わった作品をリストから削除していると、誤ってまだ観ていない作品を削除してしまいました。

すると、ウォッチリストに追加している作品にも関わらず、リストに表示されなくなりました。それを解決したお話です。

環境

• Play Station 4 システムソフトウェア: 7.51
• Prime Video: 3.13

元に戻す方法

作品を「次に観る」リストに再度表示させるには

• Amazon.co.jp にログイン
• [マイストア] -> [おすすめ作品を正確にする] -> [興味が無い商品] を表示
• 再度表示させたい作品の「興味がありません」のチェックを外す

事で解決します。

余談： 「次に観る」に表示されなくなる条件

非表示になる条件は以下の2つがあります。

• 観ていた作品を視聴履歴から削除する
• 「興味が無い商品」として登録する

特に後者の場合、ウォッチリストに追加していても表示されません(前者は未確認)。

PS4 の Prime Video で「リストから削除」を実行すると「興味が無い商品」に登録される、後者の挙動を取ります。

Web の Prime Video では「このシーズンを表示にする」という名前に変わっていますが、こちらも後者の挙動を取ります。

なので「興味が無い商品」の登録から作品を削除すると、リストに再度表示されるようになります。

参考

• Amazon | 本, ファッション, 家電から食品まで | アマゾン
  
• Amazon.co.jp: プライム・ビデオ: Prime Video
• Amazon プライムビデオの”次に観る”から消す『視聴履歴を確認』

GitHub へ push した際に Docker Hub で docker image を自動 build する

過去に「GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した」という記事を書きました。

前回は image の build を GitHub で行なっていましたが、今回は Docker Hub で build するように変更したお話です。

Docker Hub で docker image を build する

GitHub と連携した automated build という機能を利用しました(設定方法はドキュメント参照)。

前回同様、GitHub に push すると自動的に Docker Hub に image が更新されます。

これまた前回同様、以降は作業ログ等です。

何故構成を変更したのか

image を更新する為に Docker Hub を触っていた時、 GitHub 連携の存在に気付いた為です。

ちなみに、更新していた image は latex-make というもので、MacTeX をインストールせずに LaTeX を実行できる image です。

更新内容は TeX Live 2019 から TeX Live 2020 へのアップデートでした。

GitHub Actions 作成時に気にしていた3つの条件のゆくえ

過去の記事では以下の3つの条件を気にしていました。

• Dockerfile が増えた場合も自動で対応する
• Dockerfile や関連ファイルに更新が無い Image は Push しない
• GitHub Actions だけでなく、ローカルの環境でも build できる

第1条件と第2条件は、 Repository を分割して解決としました(latex-make, webpage-title)。

第3条件はビルドスクリプトをローカルマシンに残す事で解決としました。

構成を変更して良かった点

• 他の image の README を参考にした結果、 README が整備された
• latex-make には使用例が無かったので追記した
• shields.io を利用して image のサイズ等のバッジを追加
• GitHub/Docker Hub の README を(手動で)統一
• Docker Hub に automated build のログが残るようになった
• 前回は「push したユーザは atton, push 時刻」程度の情報しか無かった
• ログイン情報を書くが必要無い
• 連携時に Docker Hub から GitHub へ権限を要求しているので docker login を実行する必要は無い
• 具体的に言うと GitHub Actions ではログインパスワードを Secrets に書いていた
• なので、Docker Hub のログインパスワードを変更後、Secrets を更新しないと docker login に失敗する

構成を変更して良くなかった点

• 移行作業が手作業だった
• 対象となる docker image が2つのみだったので、手作業で移行を行なった
• 仮に docker image が多かった場合、移行スクリプト等を書く必要があったかもしれない
• 第2条件が若干緩くなった
• master が更新された際に build が行なわれるので、 README だけの変更 commit でも build が発生する
• git の tag をトリガーにして build する、等の設定で修正可能
• しかし現状の image の tag は latest しか無いので放置中

GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した

私は作成した Dockerfile を GitHub で公開しています(前回の記事の atton/webpage-title も含む)。
Docker Image を手動で管理するのは面倒なので、何らかの形で自動化する事にしました。
最終的に、 Dockerfile が更新された際に build して DockerHub に push する GitHub Actions を作成しました。

GitHub Actions を作成する際に考慮した条件

• Dockerfile が増えた場合も自動で対応する(現時点では2つ)
• Dockerfile や関連ファイルに更新が無い Image は Push しない
• GitHub Actions だけでなく、ローカルの環境でも build できる

具体的な GitHub Actions の内容

作成した .github/workflows/build-and-push.yml とbuild.sh は以下です(commit: 427f143)。

自動化できたので手動 push の必要は無くなりました。べんり。

これ以降は作業ログなどを書いておきますが、かなり長いです。

第一条件: Dockerfile が増えた場合も自動で対応する

この条件については、特定の構成をしているディレクトリを build 対象にする事で対応しました。具体的には

• ディレクトリ名は任意
• ls と [ -d ] で確認
• ディレクトリの直下に Dockerfile が存在する
• ls と [ -f ] で確認

といったディレクトリです。なお、ディレクトリ名は Docker Image の tag を決める際に使っています。

第二条件: Dockerfile や関連ファイルに更新が無い Image は Push しない

Docker Image を自動 build する際、最初は elgohr/Publish-Docker-Github-Action@master を使っていました。

ここで問題が発生。README.md を変更しただけの commit でも Docker Image の更新が行なわれました。

幸い、GitHub Actions の step では if が使えるようなので試してみましたが改善せず。

elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。

なので elgohr/Publish-Docker-Github-Action@master は利用しない方針に変更。
使わない事になりましたが、 entrypoint.sh に書かれた(docker login/logout など)内容は参考にできそうです。

さて、次は「Dockerfile や関連ファイルに更新が無い」事を判定をできれば解決しそうです。ググってみると

• $ git diff-tree --no-commit-id --name-only -r ${{ github.sha }}

で確認できるとの事。ではこれを grep して exit code で判定すれば解決、しませんでした。

更新の有無に関わらず、全ての grep の exit code が 1 になっていました。
加えて、ローカル環境では想定通りの exit code が得られるので、どうやら原因は実行環境固有のようです。

「ローカルでは動くが、別環境では動かない」という悲しい事態なので、 printf debug で少しずつ状態を確認していきます。

• git は存在するか
• git の version は何か
• git は実行できるか
• remote origin は存在するか
• commit log は辿る事ができるか
• grep の version は何か
• ...

結果、「actions/checkout@master を使うと repository の情報が消える(?)」事が判明しました。具体的には

• git コマンドは実行できる
• git show を行なうと、全ファイルが新規作成扱いになっている
• origin を fetch しても commit が取得できない

という謎の状態でした。その為、 actions/checkout@master は利用せずに直接 git clone を実行。
clone した repository では diff-tree が実行可能で、更新の有無が判定可能になりました。

余談: 第二条件の部分を書いている時に思った事

• elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。
• Pull Request を作成して提案する手がある
• 「ローカルでは動くが、別環境では動かない」
• GitHub で動作 Image を提供している可能性がある
• 「actions/checkout@master を使うと repository の情報が消える(?)」
• 今は git clone で対応できるが、 branch の指定といったオプションに対応できない

第三条件: GitHub Actions だけでなく、ローカルの環境でも build できる

この条件は「ローカル環境でも Docker Image を作成可能」にする為につけました。メリットとしては

• 問題発生時の再現に使用できる
• commit 前の Dockerfile も試しに build できる
• 新しい Image 作成時の build が楽

等があります。なお、この条件は build.sh に与える引数の有無で解決しました。

まとめ

結構な文量になりました。debug の説明を含めると長くなりますね。

結果的に「uses を排除して自前の run で記述する」というオレオレ GtiHub Actions で解決。

前回も書いた気がしますが、「個人的には十分満足しているので良しとします。」

参考文献や関連した文献など

• GitHub - atton/dockerfiles: Dockerfiles of published my docker images
• atton.blog: chromium-browser を使って記事のタイトルを取得する
• atton's Profile - Docker Hub
• Set TZ in "latex-make" image · atton/dockerfiles@427f143 · GitHub
• Publish Docker · Actions · GitHub Marketplace · GitHub
• Setup GitHub Actions for publish atton/webpage-title · atton/dockerfiles@6781d4e · GitHub
• Workflow syntax for GitHub Actions - GitHub Help
• GitHub - elgohr/Publish-Docker-Github-Action at 5d8ac991f54837cdbd0b34fc627e9e83c500fa43
• Publish-Docker-Github-Action/action.yml at 5d8ac991f54837cdbd0b34fc627e9e83c500fa43 · elgohr/Publish-Docker-Github-Action · GitHub
• Publish-Docker-Github-Action/entrypoint.sh at 5d8ac991f54837cdbd0b34fc627e9e83c500fa43 · elgohr/Publish-Docker-Github-Action · GitHub
• Find what files changed in a pushed commit? - GitHub Actions - GitHub Support Community
• Checkout · Actions · GitHub Marketplace · GitHub

chromium-browser を使って記事のタイトルを取得する

私はブログに記事を引用する際、 URL だけ書く事はあまりしません。
何かの文字列に関連付けたり、記事のタイトルに関連付けます。特に後者は参考文献の場合によく行ないます。
これが結構面倒なので、タイトルを取得する Docker Image を作りました、というログです。

環境

• OS: macOS Mojave 10.14.6
• Docker for Mac: version 19.03.8, build afacb8b

実行例

• $ docker run --rm atton/webpage-title 'https://attonblog.blogspot.com/2020/04/upgrade-awscli-with-linked-python38.html'
• => atton.blog: Homebrew で awscli を upgrade して、依存の keg-only python@3.8 を link する
• '、' は curl で取得すると escape されて 、 になる事についても問題無し。

作成した経緯

最初は curl に grep で title タグを取得する、くらいの shellscript を使っていました。

それが次第にタグの attributes を考慮したり、sed を挟んだり、と色々拡張する事に。

最終的に『header に title は無く、JavaScript で後から設定する』サイトに遭遇。これは curl では厳しい。

この際ブラウザを動した方が色々と問題解決できるのでは、という事で chromium を headless で動かす事にしました。
DockerHub の repository は atton/webpage-title で、Dockerfile は GitHub に置いてあります。

記事のタイトルを取得する為だけに大仰なのでは、という感もあります。
ですが、現状タイトルの取得に失敗した事が無いので、個人的には十分満足しています。