Masteries

技術的なことや仕事に関することを書いていきます.

GitHub Actionsの知見ご紹介

今更ですが, ここ最近ちまちまとGitHub Actionsをしています.

github.co.jp

個人的にはこういうのイジるの大好きなので, 新しいおもちゃをもらった子供のようにはしゃいでいます. 今回は, その中で知った知見などを雑多にご紹介します.

Pull Requestでコケた時にRe-run jobsするとactions/cacheアクションが正常に動作しない

GitHub Actionsには, 依存ファイル(例えばPerlならlocalとか, Node.jsならnode_modulesとか...)をキャッシュする, actions/cacheアクションが公式から提供されています.

github.com

このアクションを使っていて, かつon: pull_request のようにしてPull Requestをフックとしてワークフローを実行するとき, Re-run jobs(再実行)を実行すると, 次のような警告の文言が出て正常に動作しない問題が存在しています.

[warning]No scopes with read permission were found on the request.

これはあくまでwarning(警告)なので, キャッシュが取得できなかったものとしてワークフローの処理は継続します. そのため, 「actions/cacheでキャッシュがあれば, 必ず取得する」ことを前提とするワークフローを作っていると, 意図しない挙動になる可能性があります.

詳しくは次のIssueに記載されています.

github.com

2020年4月13日現在, この問題は開発陣に認識されてはいるものの, まだ修正は完了していないようです.

github.com

回避策としては... 空commitをpushすれば動くっちゃあ動くのですが, それはどうなのか... という感じですね. 一応 on: push としてpushをフックとすれば問題なくRe-run jobsできる... という話を聞きましたが, 自分はまだ試していません. 他の手としては, S3などにファイルを設置して, それを引いてくるなどの作戦もありそうです.

actions/cacheアクションは時折キャッシュの取得に失敗することがある

またもやactions/cacheアクションの話題です. タイトルにある通りで, actions/cacheアクションは時折次のような警告を表示してキャッシュが存在していたとしてもキャッシュの取得に失敗することがあります:

[warning]connect ETIMEDOUT xxx.xxx.xxx.xxx:443

github.com

これもwarning(警告)なので, キャッシュが取得できなかったものとしてワークフローの処理は継続します.

この問題も開発陣には認識はされていて, 原因はGitHub Actionsのランナーとキャッシュを保存するクラウドストレージの間のネットワークの問題とのことです. 自分たちの環境では, 1つのワークフローから一度に複数のジョブを走らせて, その全てで同じキャッシュを(actions/cacheを使って)引く... ということをしているので, こういった事象が起こりやすいのかもしれません.

また, 上記のIssueには, 「キャッシュアクションはベストエフォートで, もし失敗した時はそれ以降のステップでキャッシュされていたはずのコンテンツを再生成可能であると想定している(Please note, however, that the cache action is "best effort" and assumes that if it fails, the subsequent steps can recreate the cached content.)」と書かれているので, actions/cacheアクションを利用するときはその点考慮してワークフローを作る必要がありそうです.

Pull Requestでactions/checkoutを使うとmerge commitになる

こちらもまた公式が提供するアクションとして, Gitリポジトリをcheckoutするためのactions/checkoutアクションが存在します.

github.com

Pull Requestでactions/checkoutを使ってGitリポジトリを取得すると, HEAD がmergeコミットになっています. このままワークフローの中で新しいbranchを作ってcommitしてpushしてPull Requestを作ると, 差分に次のようなmergeコミットが含まれてしまいます.

f:id:papix:20200413225616j:plain
赤線部がmergeコミット

ちなみにGitHub Actionsのワークフロー内でPull Requestを作ったりといったGitHubの操作をしたい時は, actions/github-scriptを使うのが便利そうです.

github.com

...で, この問題についてはきちんとREADME.mdを見ましょう, という話で, Checkout pull request HEAD commit instead of merge commit という項に解決策が書かれています:

- uses: actions/checkout@v2
  with:
    ref: ${{ github.event.pull_request.head.sha }}

README.mdのUsageには, ref以外に指定可能なオプションの解説があるので, 「actions/checkoutアクションでこういうこと出来ないかな...?」と思ったら改めてREADME.mdを一通り眺めると良さそうです.

まとめ

備忘録がてら, GitHub Actionsをしている時に気づいた事, ちょっと躓いたポイントなどをまとめてみました. ここ2週間くらいGitHub Actionsに熱中していますが, 公式が提供する各種アクションが便利(actions/cacheはちょっとハマりポイントが多かったですが...)ですし, GitHubと良い意味で密結合していて便利なので, 引き続きいろいろやっていって知見を共有できればと思っています.

Git submodule 向き先 変更

最近いろいろあってGitのsubmoduleの向き先を変更する機会があったのですが, 2回やって2回ともやり方を忘れていてググる羽目になったのでメモ.

qiita.com

基本的にはこちらの記事に掲載されている手順を踏めばよくて,

  • .gitmodules の向き先を書き換える
  • git submodule sync する

...でよさそう. 以上忘備録でした.

英語学習としての Perl/perl5 購読

最近英語学習をじわじわと進めているのですが, その一環としてGitHubのPerl/perl5を購読する活動(?)をはじめました.

github.com

去年の11月辺りから, Perl5の開発がGitHubが主軸になるように変更されていて(過去のIssueとかも移植されている), 手軽にContributeしたり, IssueやPull Requestを追えるようになりました.

購読して何をしているか? と言うと, 具体的にはGmailに届いたIssueやPull Requestの通知を, タイトルを見て面白そう!!! と思ったものを中心に空き時間に眺めていく, という感じでやっています. iPhoneだと, よくわからない単語を長押しして「調べる」とすると, 英和辞書とか開けるので, 移動中でもサクッと読めて便利です.

ひとまず英語を目にする, 英文を読む機会を増やそう, という施策で始めた感じですが, 何れは何かしらのContributeもできればいいかな〜, と思っています.

The Perl and Raku Conference in Amsterdam 2020にproposalを出しました

去年, 「PerlCon 2019」に参加してとても良い経験が出来たので, 今年も行くぞ!!! ということで, 「The Perl and Raku Conference in Amsterdam 2020」にproposalを出しました.

developer.hatenastaff.com

去年, 「PerlCon 2019」に参加したときの様子はこのエントリに書きました.

proposalのネタ

去年は「Perl in Japan」ということで, 日本のPerl界隈の様子を話してきたのですが, 今年は何について話そうかな〜, と考えた結果, 拙作のClass::Accessor::Typedについて話そうかなと思いました. Class::Accessor::Typed, MooやMouseなどのオブジェクトシステムと, Class::AccessorやClass::Accessor::Liteのようなライブラリのちょうど真ん中くらいの立ち位置にあると思っていて, 程よく便利で使い勝手も良いと思っており, 紹介しつつ新しいアイデアなどを得ることができればいいなー, とか思ったりしています.

title: Introduce of Class::Accessor::Typed

In this talk, I introduce Class::Accessor::Typed.

When you want to implement a new object in Perl, which CPAN module do you use?
We have many choices. One of the options is using Object System like Moose, Moo, and Mouse.
And another option is using automated accessor generator like Class::Accessor and Class::Accessor::Lite.
Of course, using "bless" is one of the simple solution.

In this case, usually, I use Class::Accessor::Lite.
Because that is lightweight, fast and readable.
But, Class::Accessor::Lite does not have type system.
So, I think that It is difficult to use in large scale system development.

To solve this problem, I implemented Class::Accessor::Typed.
This module is fast and readable like an automated accessor generator and supports type system using Mouse::Util::TypeConstraints.

In this talk, I want to talk about function, implementation method and benchmark result about this module. 

(英文は一応grammarlyを通したりチェックしていますが, 明らかにおかしいところがあったらTwitterのDMとかでこっそり教えて下さい...)

正直なところ, もう航空券など全部手配してしまったので, proposalの採否に関わらず参加する予定なのですが, 折角なので話せると良いですね. 海外のカンファレンス, やっぱり勇気は必要とは思いますが, とはいえいろいろな面で得るものが多いので, 皆さんも是非どうですか. 僕と一緒に英語を勉強しようよっ!!! (最近サボリ気味なので, 夏に向けて頑張らねば... と思っています)

TypeScriptの型について学んでいた, そしてCLIでTypeScriptのコードを実行する方法についての備忘録

業務でTypeScriptを書いている訳ですが, 「ぜんぜんわからない, 俺は雰囲気でTypeScriptをやっている」という感じなので, まずは型について理解を深めようと思って, Qiitaの次の記事を読んでいました:

qiita.com

日頃, Perlというゆるふわな言語を主に使っているので, 型についての考え方とかスッと入ってこなくて, やっぱり難しいですね〜!!! という気持ちになっていました. とはいえ, これまで雰囲気で書いていた部分について, 「ナルホドそういう意味だったのか...」みたいな発見があって学びがありました.

引き続き以下の記事を読もうかと考えています:

qiita.com

qiita.com

「これも読んでおくといいぞ!」というテキストがあれば是非教えて下さい!!!!

CLIでTypeScriptのコードを実行する方法

ある言語の仕様について学習するとき, 実際に動作する環境を作って, 適当なコードを書いて動かして試行錯誤する... というのは良い方法だと思っています.

というわけで今回は, CLIでTypeScriptのコードをシュッと実行する環境を作って, 実際にTypeScriptのコードを実行しながらテキストを読んでいくことにしました.

qiita.com

今回は上記のエントリを参考にして, ts-node というライブラリを使うことにしました.

$ npm install -g typescript ts-node

とすると, ts-node というコマンドが使えるようになり,

$ ts-node /path/to/script.ts

みたいな感じでTypeScriptのコードが実行出来るようになります. 型なども考慮されるので, こういった学習用のサンプルコードをシュッと実行するにはとても有用でした.

...っていうかよく見たら普通に社の同僚の書いたエントリでした. こういう時無意識に同僚のエントリが出てくると「オッ!」となりますね. サンキューです!!!