今朝見た夢、まったく関係ない話から、途中から突然祖父が登場したりした。夢に登場する祖父は実際とはかなりかけ離れているもので、起きてからなんだそりゃとなりがち。ときたま登場するので、なんだかんだ好きだったのは本当だろうと思う。
続きを読むprogress要素でモアイまわしができる
progress 要素で遊ぶシリーズ。
まず普通に x と y を追従するようなものをつくるとこう。 Glitch で遊んでたのをここにコピペしてるのでなんか変かも。
x と y を入れ替えると、もう奇妙な感覚になる。
つまりこれをうまく使って遊べそう → これモアイまわしじゃん、ということに気づいたのだった。
300x300で, x と y は...
やっぱり座標が変そうなので Glitch 版も貼っておきます。
GIF で貼っておくと、こういう動きをするはず。
追記: もちろん progress 要素じゃなくてもよくて、月とかでもよい。こっちのほうが回転の様子とかはわかりやすい。
MDN <progress>: The Progress Indicator element - HTML: HyperText Markup Language | MDN を見ていたら、 ::-webkit-progress-bar みたいな疑似要素があって、色とかを変えられるようだった。 ::-webkit-... のほうしか指定してないので Chrome 系じゃないと色が変わらないかも。
あと MDN 見てると meter 要素 <meter>: The HTML Meter element - HTML: HyperText Markup Language | MDN というのもあって、今回みたいな用途だったら meter 要素のほうが比較的あっている？かも？ しかしモアイの回転度が進捗かというとそんな気もする。
本家モアイまわしはこちら。子どものころから大好きなゲームです。
www.skt-products.com
progress要素並べまくるとスペクトラムアナライザみたいな表示ができる
progress 要素はこういうやつ <progress>: 進捗インジケーター要素 - HTML: ハイパーテキストマークアップ言語 | MDN
並べまくるとこうなる。 DOM なのでたぶん遅そう。
値はランダムなだけだけど、こういう音楽といっしょに楽しめる。
www.youtube.com
シェルで簡単ストップウォッチ
ルービックキューブを揃えるまでの時間を測りたい！手元にシェルしかない！そんなときはこう
$ time read
real 0m2.951s
user 0m0.000s
sys 0m0.000s
read コマンドで入力を待ち受けていた時間が出てくれる。これで計測開始 (コマンド開始) と 計測終了 (read に入力) の両方を Enter キーでできるのでわかりやすくて便利。
↑は bash で試したけど、 zsh では $ time (read) とするとよいようだった ($ time read だと何も出ない。ビルトインのコマンドは(カレントのシェルで実行されるので)計測されないので、括弧をつけてサブシェルで実行させると計測できる、とのことだった zsh - `time echo` got no output - Unix & Linux Stack Exchange)。
GitHub Actions workflowのannotationを一覧するシェルスクリプトを書いた
三行
- GitHub リポジトリの actions の実行に、エラーや警告 (deprecation など含む) の annotation がつくことがある
- annotation 一覧みたいなものはないので、 workflow がたくさんあると、それぞれの annotation を見て対応するのが大変
- 実は actions の更新とかは Renovate でできるので大変じゃないこともある！
- markdown で一覧するためのシェルスクリプトを書いた GitHub - hogashi/list-workflow-annotation-for-repo
解説
困り
annotation といっているのはこれ (画像) *1 。この画像の場合、 Node.js 16 を使う actions は非推奨なので Node.js 20 を使うものに更新してね、具体的には actions/checkout@v3 と actions/setup-node@v3 だよ、と言われている。
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, actions/setup-node@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.
書かれていることに沿って更新したらいいのだけど、こういうのっていろんな workflow にそれぞれ書いていて (特に actions/checkout とか)、それぞれ annotation がついている。どれで何が出ているかの一覧ができないので、結構不便。
先行研究と困り
一覧するためのツールとして、 gh コマンドの拡張機能という先行研究がある。最近の workflow の実行を取ってきて annotation を一覧するというもの。これはかなり便利で見やすくて、小さいリポジトリならこれで戦える。
swfz.hatenablog.com
問題は workflow がたくさんある大きいリポジトリで、最近の実行だけ見ていると間に合わない。ので、リポジトリにある workflow それぞれについて、最も最近の実行の annotation を取ってきたい。
作ったもの
という動機で書いたのが今回のシェルスクリプト。
github.com
gh コマンドを叩きまくって、 workflow 一覧 → それぞれの check suite の最新の run 一覧 → それぞれの annotation 一覧 という順番で取ってくる。 GitHub Actions は登場人物が多くて難しい (理解してないだけでもっと簡単な方法があったりするのかも……)。
シェルスクリプトなので、 git clone でもコピペでもいいので手元に持ってきて、素朴にこう実行したら動く (gh とか jq とかは必要なので適宜入れてください)。
$ ./list-workflow-annotation-for-repo.sh owner/repo > annotations.md
実行すると markdown で出力される (標準出力に出すので↑みたいにするのがおすすめ)。改行とかはあんまり頑張ってないので見づらいかもだけど、例えば GitHub issue に貼るとこういう感じで見れる。各見出しは、該当の annotation が出ている workflow やその実行の画面へのリンクになっている。
出力される markdown はこんな感じ (クリックで開く)
## [CodeQL](https://github.com/hogashi/twitterOpenOriginalImage/blob/master/.github/workflows/codeql-analysis.yml) Latest run: [https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468391494](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468391494) ### [Analyze (javascript)](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468391494/job/26084641757) ## [git-issue-release](https://github.com/hogashi/twitterOpenOriginalImage/blob/master/.github/workflows/git-issue-release.yml) Latest run: [https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468384396](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468384396) ### [action](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9468384396/job/26084617386) ``` Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: kouki-dan/git-issue-release@v1. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/. ``` ``` The following actions uses node12 which is deprecated and will be forced to run on node16: kouki-dan/git-issue-release@v1. For more info: https://github.blog/changelog/2023-06-13-github-actions-all-actions-will-run-on-node16-instead-of-node12-by-default/ ``` ## [Node.js CI](https://github.com/hogashi/twitterOpenOriginalImage/blob/master/.github/workflows/nodejs.yml) Latest run: [https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9471522972](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9471522972) ### [check](https://github.com/hogashi/twitterOpenOriginalImage/actions/runs/9471522972/job/26094921517) ``` Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3, actions/setup-node@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/. ```
これを見ながら、順番にバージョンを上げたりしていったらよい。
それ Renovate でできるよ
これ書いてて気付いたんだけど、 actions の更新は Renovate がやってくれる。なので、いっこ annotation を見かけたら、 Renovate の Dependency Dashboard issue を見に行って、チェックをつけたら終了できる。便利ですね〜
今回書いたシェルスクリプトの存在意義を頑張ってこじつけると、 annotation というのは ("使ってる actions が古いよ"だけではなく) エラーや警告全般が存在するので、何かエラーや警告が出ているかどうかを見て回る、というのに使える。
例えば、 typo しているとエラーになるわけだけど、そういうときはこういう annotation がつく。エラーだと当然実行が失敗するので気付けるけど、警告系だと気付かないことも多そうだし、まあまあ使えることもあるかも。
The workflow is not valid. .github/workflows/nodejs.yml (Line: 9, Col: 5): Unexpected value 'runs-o' .github/workflows/nodejs.yml (Line: 9, Col: 5): Required property is missing: runs-on
Docker Compose 1.27.0以降ではdocker-compose.ymlにversionを書く必要がなくなっていた
あらすじ
docker-compose.yml でトップレベルの version 要素を指定していると、 WARN[0000] (...)/docker-compose.yml: `version` is obsolete と表示される。インターネットを見ていくと version は指定しなくて良い、消したらいい、という記事がたくさん出てくるし、たしかに公式のドキュメントにも obsolete と書かれている Version and name top-level elements | Docker Docs。
Version top-level element (obsolete)
https://docs.docker.com/compose/compose-file/04-version-and-name/
The top-levelversionproperty is defined by the Compose Specification for backward compatibility. It is only informative and you'll receive a warning message that it is obsolete if used.
しかし昔は必要だった記憶があって、気になって issue/p-r を見ていったら、 2020年あたりにはすでに optional になっていたようだった。
時系列
提案
version を書くのをやめよう、という issue はこれ Validate compose file on supported API, not version · Issue #7201 · docker/compose 。
大まかに書くと「Docker エンジンの API バージョンと docker-compose.yml のバージョンの食い違いによるエラーや、妙に古い記述から version をコピペしていて yml のパースに失敗するなど、色々問題が起きている。 docker-compose.yml の version の記述をやめ、とにかく Docker エンジンの API バージョンを参照して判断することにすれば、解決できるはずだ」という提案。結局実行するときにはエンジン側で対応している API しか使えないのだから、そっちのバージョンだけを真として扱うのが良いだろう、というのはわかりやすいし確かに感がある*1。
仕様の変更
この内容が Compose Spec community という場所で議論され Don't require version · Issue #13 · compose-spec/compose-spec 、話し合いの結果 (2020/6/4 に) 受理されている。議論のすべてが issue 上に載っているわけではなさそうに見える (激論中に突然受理されているみたいになっている) けど、「破壊的変更をしたくなることは未来永劫ないのか」「逆にどの機能が使えるのかわかりづらくないか」みたいなことが議論されていそう。
この結果、仕様が変更され Make `version` optional and define strict/standard/loose parsing mode by ndeloof · Pull Request #82 · compose-spec/compose-spec 、 version は後方互換性のために書けるが、単に付記する情報くらいの扱い (この値を使って何かするわけではない) 、ということになっている。
## Version top-level element - A top-level version property is required by the specification. Version MUST be 3.x or later, legacy docker-compose 1.x and 2.x are not included as part of this specification. Implementations MAY accept such legacy formats for compatibility purposes. + Top-level `version` property is defined by the specification for backward compatibility but is only informative.https://github.com/compose-spec/compose-spec/pull/82/files#diff-bc6661da34ecae62fbe724bb93fd69b91a7f81143f2683a81163231de7e3b545
実装の変更
docker-compose の実装のほうで version を optional にするのはこの p-r でやっていて Merge V2 - V3 compose file formats (optional version field) by aiordache · Pull Request #7588 · docker/compose v2, v3 の docker-compose.yml のスキーマを一緒にしようという趣旨になっている。 master ブランチにマージされたのは 2020/7/27 。
version に書かれたバージョンの値ごとにスキーマを確認するのではなく、とにかくひとつのスキーマを真とするようになったので、 compose/config/config_schema_v2.0.json, compose/config/config_schema_v2.1.json, ... みたいなファイルが全部消えて compose/config/config_schema_compose_spec.json に統一されているのが感動的 (v2 と v3 もまとめられていることがわかる)。
この変更は (1.27.0-rc1 を経て) Release 1.27.0 · docker/compose で 2020/9/7 にリリースされている (リリースノートの 1.27.0 の内容にも同じことが書かれている)。以来 version は書かなくてよい状態だったのか……。
https://github.com/docker/compose/releases/tag/1.27.0
- Merge 2.x and 3.x compose formats and align with COMPOSE_SPEC schema
しかしいつから `version` is obsolete の warn が出ていたのかはよくわからなかった。 2020年ごろにこの warn を見た覚えがないけど、本当に出てなかったのか単に warn を見過ごしていたかあんまり自信がない。インターネットを見るとなんとなく 2024年の情報が多いので、最近のどこかのバージョンでちゃんと warn が出るようになったのかな……。
ちなみに
docker-compose.yml と書き続けてきたけど、実は今は設定ファイル (Compose file) のファイル名は compose.yaml が推奨されている *2。 拡張子は yml でも大丈夫で、 docker-compose.yaml (.yml) も後方互換性のために動くようになっている。公式のドキュメントはこれ https://docs.docker.com/compose/compose-application-model/#the-compose-file 。
The default path for a Compose file is
https://docs.docker.com/compose/compose-application-model/#the-compose-filecompose.yaml(preferred) orcompose.ymlthat is placed in the working directory. Compose also supportsdocker-compose.yamlanddocker-compose.ymlfor backwards compatibility of earlier versions. If both files exist, Compose prefers the canonicalcompose.yaml.
*1:一応 1.x 系では version の記述を使っていた、とは付記されていそうで、 2.x 以降になってから不要にできるようになった、と書かれていそう？ だけどこのあたりはあまり読み取れなかった
*2:p-r でいうとこのあたり Update README.md to use standard `compose.yaml` file name by johnthagen · Pull Request #11233 · docker/compose
