2020/11/07

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 で対応できました。

2020/08/16

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 では「このシーズンを表示にする」という名前に変わっていますが、こちらも後者の挙動を取ります。
なので「興味が無い商品」の登録から作品を削除すると、リストに再度表示されるようになります。


参考

2020/07/19

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 しか無いので放置中

2020/06/09

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 は利用しない方針に変更。
使わない事になりましたが、 entrypoint.sh に書かれた(docker login/logout など)内容は参考にできそうです。

さて、次は「Dockerfile や関連ファイルに更新が無い」事を判定をできれば解決しそうです。ググってみると
で確認できるとの事。ではこれを 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 で解決。
前回も書いた気がしますが、「個人的には十分満足しているので良しとします。」


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

2020/06/01

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 に置いてあります

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