wandbox-api version 0.9.38 をリリースしました

wandbox-api 0.9.38 をリリースしました。
0.9.37〜0.9.38 で新環境の Wandbox への対応と不具合修正をしています。
詳細はリリースノートを確認してください。
https://github.com/srz-zumix/wandbox-api/releases/tag/v0.9.38
https://github.com/srz-zumix/wandbox-api/releases/tag/v0.9.37

新しい Wandbox ではいくつかの言語が削除されました。（CoffeeScript,CMake,F#,Rill）
また、各言語のコンパイラーバージョンも大幅に削減されています。
これらに伴い、削除された言語、コンパイラーの alias コマンドを削除してます。

新しい環境になって、動作してない言語・バージョンもあるようなので拙作のステータスページなども確認してください。
https://srz-zumix.github.io/wandbox-status/

時間が取れたら、wandbox-builder に環境の修正 PR でもしていきたいです。
以上。

GitHub Actions の action 開発者にお願いしたいメジャーバージョンアップするタイミング

 GitHub Actions とっても便利ですね！
個人開発ではもちろんのこと、会社でも便利に使っています。
使うだけではなく action を作ったりもしてます。

さて、本題に入りますが、
会社の GitHub が Enterprise のため github.com の方にはあるが Enterprise にはまだない機能や環境を使われると action が動かないことがあります。
幸い使用する action のバージョンを固定することで回避できるのですが、できることならそのような変更時にはメジャーバージョンアップしてほしいなと思ってます。
（SemVer 採用してる前提ですが）メジャーバージョンでバージョン固定しているケースが多いため、マイナーバージョンアップだと管理下の全リポジトリに対してバージョン固定をして回らないといけなくてすごく面倒くさいのです。。
メジャーバージョンアップならこのような破壊的変更を自然に避けられるので、何卒。
（まぁ Enterprise 使ってないとそういった事情はわからないので仕方がないとは思ってますけど）

実際にあった例としては、

• 「using: "composite"」
  Composite Action が Enterprise でまだ使えなくて動かなくなった。
• 「using: "node16"」
  Enterprise はまだ「docker」か「node12」しか使えない状態だったので動かなくなった。（こっちは Enterprise のアップグレード以外に方法があるなら知りたい）

がありました。
とりあえず using 変えると Breaking Change になるようにするのが良さそうですね。

この辺を自動で対応するなら using の差分があったらラベルつけるとかできればなんとかなりそう。（actions/labeler だとファイル単位なので別のやり方が必要）
なんかいい方法見つけたらブログで書きたいと思います。

以上。

bash スクリプトの実行中上書き動作が ansible copy module で再現するのか試してみた

きっかけはこちら 「スーパーコンピュータシステムのファイル消失のお詫び」
bash のスクリプト実行中にファイルを上書きすると、実行中の場所から上書き後の状態で実行される挙動（以下、本挙動）があり、それにより意図しない処理がされてしまったという感じ。
わかりやすい例はこの辺を参考にしてください。

Tips: 実行中のシェルスクリプトを書きかえるときには - Qiita
bash スクリプトの実行中上書き動作について

この記事は ansible で本挙動と同じことが起こり得るのかの検証記事です。

さて、結論から言うと・・・「再現しない」でした。安心してください。
仕事で ansible 使って .sh を配布してたのでちょっと心配だったんですよね。良かったです。



では、以下から検証内容を詳しく見ていきます。
（公開当初に検証用の repository が private になってました。すみませんでした）

bash のスクリプト実行中の上書き実験 by srz-zumix · Pull Request #3 · srz-zumix/ansible_dotfiles

こちらの PR で検証コードを書いて、GitHub Actions で実行してみました。
検証コードは↑で紹介した記事のサンプルスクリプト（echo foo/bar）を使っていて、copy module を使ったファイルコピーと shell module で cp コマンド使ってコピーした場合を検証しています。
このへん→https://github.com/srz-zumix/ansible_dotfiles/blob/main/roles/bash-cp-test/tasks/test-loop.yml#L19

実行中に上書きするために async を使用しています。
async タスクの完了待ちは async_status で状態を確認して待っています。
こういう書き方は普段しないので勉強になりました。

この ansible を playbook すると再現した場合は「bar」、再現しなかった場合は「foo」と表示されます。
結果はこちら

cp コマンドでは「bar」、copy module では「foo」でした。
cp コマンドの場合に再現しているので検証コードには問題がないと言えます。
よって copy module では本挙動は再現しないと言えます。
本挙動が発生するかしないかは inode が変わるか変わらないがポイントとなっており、コピー前後の inode をデバッグ出力もしています。上のスクリーンショットのログは cp コマンドの場合のログで、inode が変わってないことが見て取れます。（スクリーンショットにはありませんが、copy module では inode が変化してました）
実行結果は GitHub Actions のログでも確認できますので、詳細はそちらを参照してください。

ちなみに copy module は remote_src: true でリモートマシン内でのファイルコピーができますが、その場合も本挙動は「再現しない」です。
なぜなら copy module の実装で remote_src の true/false によらず atomic_move を使用して新しいファイルに更新しているからです。atomic_move は os.rename を使ったファイルリネームで実装されており、この atomic_move を使っていれば copy module 以外でも本挙動は発生しないと考えてよいでしょう。
（不安だったのでテスト追加した。https://github.com/srz-zumix/ansible_dotfiles/pull/4 cp コマンドの対としては remote_src のほうが適切だったと後で思った）

以上。