GitHub Actions の Composite Action で post 処理を実現する方法の訂正

GitHub Actions の Composite Action で post 処理を実現する方法

こちらの記事で「./」でパス指定すれば OK って書いたのですが、これは自分自身をチェックアウトしてたのでできたことでした。
このアクションを使う場合はアクションの実体は GITHUB_ACTION_PATH 環境変数の指す場所にあり、uses をパス指定する場合は workspace からの相対パスになるのでこの方法ではダメというわけです。

uses で env は使えないので（静的に解決される必要があるかな？使えれば env. GITHUB_ACTION_PATH で良かったのですが）、workspace の .github/ 配下に post-action のシンボリックリンクを貼って、そのパスを指定するようにしました。

https://github.com/srz-zumix/setup-service-jenkins/pull/27

ちょっと微妙な感じもしますが、他に回避方法思いつかなかったのでこうしました。
composite action でも早く post 処理できるようになるといいなー。
（post action 用の repo or branch 用意するのも考えたけど、コードが分離するのが嫌だったのでやめました。でも、指定したパスの shell script を post 処理で実行するだけの action はあってもいいかなーと思いました。）

以上。

Git に Contribute してみた

この記事は「Gitのカレンダー | Advent Calendar 2022 - Qiita」の 15日目の記事です。

Git そのものの修正を出したい、手順ってどうすればいいんだろ？
と検索しても GitHub で OSS に貢献（Contribute）する方法みたいなのがヒットして役に立たず。
結局、公式の英語文とにらめっこして Contribute したので備忘録です。

はじめに

出した PR はこちら
https://github.com/gitgitgadget/git/pull/1406

そしてこの修正が含まれた Git 2.39 がリリースされました。

Highlights from Git 2.39 | The GitHub Blog
[ANNOUNCE] Git v2.39.0 - Junio C Hamano

Changes にアカウント名が載ってましたねぇ。嬉しい。

Contribute 方法

さて、まずはじめに Git はよくある OSS のように GitHub での Pull Request を出したらレビューされて Approve されたらマージされる。というフローではありません。
基本的にメーリングリストにパッチを送る形式のようです。

CONTRIBUTING.md

ただ、メーリングリストは自分もそう感じましたが非常にハードルが高いです。（英語だし）
そこで私は GitGitGadget に PR を出す方法で Contribute してみました。
やり方はドキュメントをたどっていけばわかりますが、日本語情報がなかったので、かなり慎重になりました。

ドキュメントはこちら MyFirstContribution

修正をする

修正するまでは他 OSS の場合とあまり変わらないですが、まず gitgitgadget/git に PR 出すのでこちらから fork しましょう。
修正したらビルドして動作確認、テストをすることになります。
この辺は README 読めばわかると思うので省略。
ちなみに今回の PR は1行修正であることと、テストってどうやる？どうやってる？って感じの内容だったのでやってません。
（実際にはやったけど自分の環境では修正と関係ないところがパスしなかった。PR 出すとテストされるのでそっちに任せました。ごめんなさい）

コミットをする

変更できたら、次は commit します。
ここは少し注意が必要です。コミットメッセージは当然英語ですが、そこは頑張ってください。

1つ目は git commit に --signoff (-s) をつける必要がある点です。このオプションを付けるとメッセージに「Signed-off-by: <user.email>」のメッセージが追加されます。
これが必須なので普段つけてない人は気をつけましょう。

2つ目は commit メッセージのフォーマットが決まっている点です。
.editorconfig で1行あたりの文字数が設定されているので、.editorconfig 対応してるエディタでコミットメッセージを編集するのをおすすめします。
コミットメッセージの1行目は変更対象のコンポーネント名を含む 50 文字以下で概要を書きます。
1行空行を空けたあとに、変更の詳細を書きます。
詳細には、コード差分からは読み取れない部分を書くことが重要です。

自分の場合、今回はとにかくメッセージの部分に時間を取られましたが、過去の commit のメッセージを参考にしてシンプルな日本語文章を書いてから、少しずつ翻訳ツールを使って英語のメッセージにしました。
（普段英語できないのにテキトーな英語使ってたが、今回はかなり気を使った。。）

プルリクエストを出す

commit したらプルリクエスト（PR）を出します。
PR を出す先は gitgitgadget/git なので気をつけてください。
やり方はこちらに記載されています。
https://git-scm.com/docs/MyFirstContribution#send-pr-ggg

PR の内容はメーリングリストに流れるカバーレターのタイトルと本文になるので、こちらもドキュメントを参考に書きましょう。

カバーレターについてはこちらに記載されているので、これを参考に PR のタイトルと本文を記載します。
https://git-scm.com/docs/MyFirstContribution#cover-letter

今回のように修正が 1 commit であれば、commit の概要をタイトルにしても良いと思います。
説明文のほうは、commit や commit メッセージでは読み取れない補足情報を書きます。
今回は簡単な内容説明と再現条件を記載しました。

これも過去の PR を参考にすると良いかもしれません。

PR 後の対応

PR を作成すると bot からのメッセージが投稿されます。
こちらにも Contribute 方法について書かれてます。
それに記載されてますが、初めて Contribute する場合は許可された GitHub ユーザー名にないため、すでに許可されたユーザーから /allow のコメントをもらう必要があります。

自分の場合は幸運なことに特になにもせずとも /allow されました。
もし /allow されない場合は issues から /allow コメントを出してる人を探すといいそうです。

（すでに /allow されたユーザーなら誰でも /allow できるっぽいので今度は自分が /allow できるってことか。つまり私に /allow してーと頼むことも可能ってことか。）

次に /submit コメントを書くと、PR の内容がメーリングリストに投稿されます。
が、その前に /preview で投稿されるメールを確認できるので、しておきましょう。
GitHub に登録してるメールにプレビューメールが届きます。
内容に問題がなければ /submit コメントを送ります。

メーリングリストの返信や patch のステータスなどがボットにより自動で PR に送られてきます。
メーリングリストで修正依頼や質問などが来たら返信する必要がありますが、今回は特に眺めてるだけで取り込まれました。（軽微な修正でしたので）
ドキュメントにそのようなケースの対応方法も書いてあったので、たぶんそれを見ながら対応すれば大丈夫だと思います。（経験しなかったので省略）

あとは勝手に進んだのであまり知見として得るものはなかったのですが、待っていたら master に取り込まれて PR は close になります。
（PR は merge されず close になります。取り込まれたかどうかは label でわかりそうです）

最後に

最後の方は待ってるだけで、これなにもしなくていいのかな？認識間違ってるかな？と不安にもなったのですが、結果的に取り込まれてそれがリリースされたのでとっても嬉しいです。
なんか、Git そのものに Contribute するというのはちょっと特別感がある気がします。

Git 自体の修正って大変そう。難しそうというイメージがありましたが、今回の PR 内容は調べてみたらそんなに難しい修正じゃなかったです。みなさんも普段 Git を使っていてなんか変だな？バグかな？と思ったら Contribute にチャレンジしてみてはいかがでしょうか？

とりあえずあまり有益な記事じゃないかもしれませんが、怖くないよってことが伝われば幸いです。ではでは。

【Make formerly Integromat】Twitter でいいねした画像を自動でクラウドストレージに保存する

最近、お絵かきをしたいなと思ってちょこちょこ描いてるのですが、今は昔よりも簡単に上達するための手法や、Twitter の投稿でお手本を見られるので、思っていたよりうまくなった気がしてます（自己満）
まぁまだまだ下手くそなんですけどね。それでも昔のなんかうまく描けないって感じの絵からは脱却できたと思う。

はい。ここまでがまっとうな言い訳なんですが、Twitter でこのひとの絵上手だな、この構図いいな、こんな塗り方もあるのね、といいねした画像がいっぱいあるのですが、参考にしたいなというときにいいねを遡るのは大変なので保存することにしました。
（決して助平心の極みではありません）

では早速シナリオへ

シナリオは 4 つのモジュールだけなので簡単な方です。
まずはじめにトリガーになる Twitter モジュールです。
※Twitter モジュールを使用するので有料プランが必要です。

トリガーは毎時設定で、「List Likes」モジュールで最大5件取得するようにしています。

When to start を過去からにしたら昔のいいねを順次5件ずつ処理されます。
（全件は取得できないです。ページング対応してないからと思われます）

次の Iterator ですが、これは１ツイートに複数の画像がついている場合があるので「Extended entities: Media[]」配列をループさせてます。

次の HTTP モジュールで取得した画像 URL からファイルをダウンロード

最後にダウンロードしたファイルを Dropbox モジュールでアップロードしてます。

アップロード先は好みで変えてください。

（サービスのモジュールがない場合は HTTP モジュールで頑張るか、FTP や SFTP モジュールになると思います）
ファイル名は複数枚画像があった場合に同じファイル名にならないように Iterator からインデックスを取って名前に含めるようにしています。
今回は単純にツイートIDをファイル名に含めるだけにしていますが、Twitter モジュールからツイートの情報が取れるので必要に応じて情報を残すと良いと思います。

実際に運用している Dropbox はこんな感じです。

いいねしておいたら勝手に保存されるので、どんどんいいねしちゃいますね！

ではでは。

git で新規ブランチ作成時の typo を防ぐ

 あまり実用的ではないものの参考までに紹介します。
（というのも最近趣味プログラミングしてなくてネタがない・・）

git でブランチ作成するときに feature って名前をつけることがよくあると思いますが、
これを typo して faeture だったり featrue だったりで push してしまうことがあります。

ただの名前だしまあそんなに気にしなくても。。と思いますが、
ブランチ切替時の入力補完が f や feat とかで止まってしまって1手順増えてしまいます。

たかが1手順とはいえ、体験すると割とストレスだし、開発メンバー全員に影響があることなので実は思っている以上に生産性を下げてしまっている。かもしれません。
（体感です。計測してるわけじゃないです。）

トイルといえるかもしれませんね。
スケールもすると思うので、改善のコスパは良い気がします。

。。少し脱線しましたが、本題へ

commit メッセージの typo チェックはよくあるけど、ブランチ名の typo チェックはあまり聞きません。
ブランチ作成時の hook はなさそうだったので、多くの人が作ってるであろうブランチ作成の alias に手を加える方法にしました。

typo 修正付きブランチ作成 alias

できた alias はこちらです。

[alias]
  cob = "!f(){ echo $1 | sed 's|/| |g' | typos - -w | sed 's| |/|g' | xargs -I% git switch -c %;};f"
  

こうなります。

typo チェックツール

今回使った typo チェックツールは typos です。
他に misspell も使ってみたのですが、feature の typo のいずれのパターンも修正できなかったので typos にしました。

typos は feature_test は分解してチェックしてくれますが、feature/test は分解されなかったので、sed で一度スラッシュを空白に変換してます。
空白にしたのは typos のあとでもとに戻すときに、都合が良いからです。
（_ だともともと _ だったものも / にしてしまう）

ちなみに typos でも faeture は feature になおしてくれますが、featrue はダメでした。
辞書とかあれば改善するかもしれませんが、今回はネタレベルで書いた alias なのでパスします。

最後に

こういったちょっとした手間でもスケールすれば効果は大きくなります。
最近は自称 SRE として改善を生業としてますが、こういったお遊びも役に立つことがあるでしょう。

以上。

【GitHub Actions】コンテキストダンプのススメ

GitHub Actions では github や job などのコンテキストから git の状態や PR の内容、ジョブの情報などが取得できます。
これらを利用してステップの条件をつけたり、処理を変えたりなどができます。
さて、このコンテキストですがどういったものがあるのかは、ドキュメントで確認できます。

コンテキスト - GitHub Docs

ただ、実際にどういった値が入っているかまではわからないですし、ランナーやジョブによって当然値は変化します。
なので、コンテキストをダンプするための repository を用意しておくととても便利です。
私は ci-spec repository でいろいろなイベントトリガーでダンプできるようにしてあります。
https://github.com/srz-zumix/ci-specs/blob/master/.github/workflows/events.yml
この情報って取れるのかな？って探すことが結構あるので重宝してます。

また、github context の json は nektos/act の入力イベントとしても使えるので、常にダンプしておくと便利かもしれません。。かも。。

今回は以上。
act のことは「ブログズミ: nektos/act で GitHub Actions のワークフローをローカル実行」と「GitHub Actions のローカル実行ツール（nektos/act）を便利にする gh extension を作った」で書いたのでよければ見て下さい。

Homebrew と git fsmonitor の相性が悪かったので対策した

「Git 2.37.0 で FSMonitor daemon が追加されたことで status が早くなったそうです」
この記事で fsmonitor の事書いてしばらく使っていたのですが、brew upgrade したときにたまに以下のエラーで失敗するようになってしまいました。

Error: Another active Homebrew update process is already in progress.
Please wait for it to finish or terminate it to continue.

これは Homebrew 3.5.7 で対応されたので、現在は発生しなくなっていると思います。

当時はあんまり調べる時間なかったので、一旦 fsmonitor を無効にしてましたが、修正 PR と Issue をみた感じ fsmonitor が homebrew の lock ファイルを掴んでしまうからみたいです。

Homebrew 3.5.7 は fsmonitor を stop させる対応となっていますが、そもそも監視しておくメリットってあるのかな？ということで、 brew 配下だけ fsmonitor を無効にする設定を紹介します。

ちなみに brew に追加する tap も git なのでそれらも無効にします。

includeIf を使って任意のディレクトリ以下の git config をカスタムする

グローバル設定は false で使いたいディレクトリだけ true にするとか、brew 配下のワーキングディレクトリすべてに git config core.fsmonitor false していけばいい話ではあるのですが、デフォルト true で使いたい＆一括 false 設定をしたいです。

そこで、includeIf を使います。

includeIf はその名の通り、条件を満たした場合のみ config を include する機能です。
リンク先のドキュメントに Example があるのでどういうことができるのか想像できると思います。

今回は brew --prefix のパス以下の場合に fsmonitor = false にした config ファイルを読み込ませます。
（brew --prefix に合わせて適宜変更してください）

これだけです。簡単ですね。
includeIf 使うと特定のディレクトリ以下で user 切り替えるとかもできるので覚えておくと良いテクニックだったと思います。

おまけ

https://github.com/jgavris/rs-git-fsmonitor

これはたまたま見つけたデフォルトの fsmonitor の hook スクリプトを Rust rewrite したやつ。
fsmonitor って true/false ではなくて hook スクリプトを指定することもできるんですね。

git status がもっと速くなるみたいですよ。
（筆者環境では差は感じられなかった）

Dagger 使ってみた

Dagger とは？

Dagger は CI/CD パイプライン用のポータブルな開発キットです。

Dagger は他の一般的な CI/CD が YAML でパイプラインを記述するのと異なり、CUE で記述します。CUE については後述しますが、YAML よりプログラミング言語に近くて柔軟性が高いって感じですかね。

CUE によって YAML ではやりづらかったパイプライン再利用が容易になっています。

また、Dagger はローカルでも CI でも、どこでもパイプラインが実行できるのが特徴です。

Dagger はすべてコンテナ上で実行されます。コンテナが動く環境上であればどこでも「同じ」パイプラインを実行できるのが Dagger であり、CI/CD ツールではなく、パイプラインを共通化するレイヤーとして機能するツールです。

CUE

https://github.com/cue-lang/cue

CUE は Configure, Unify, Execute の頭文字のようです。
CUE は JSON のスーパーセットで、CUE から JSON/YAML にエクスポートも可能です。

CUE については Dagger のページにも説明が詳しくあるのでそちらを参照してください。

https://docs.dagger.io/1215/what-is-cue/

CUE は YAML のマージ機能も備えているので↓みたいな使い方もできるみたいです。これはこれで便利そうですね。

「CircleCI の設定ファイルを分割して CUE で合成してみたら割と簡単で便利そう - Mitsuyuki.Shiiba」

今回は Dagger の話なので CUE そのものもそのうち触ってみたいです。

使ってみる

ものは試しで、使ってみました。
Dagger のサンプルとして todoapp があるのでそれでまずは動作を試してみるのがオススメです。このへんはありきたりな内容になってしまうので、省略します。

iutest に適用

iutest は筆者が書いてる C++ テスティングフレームワークです。
（まぁ最近はテスティングフレームワークの機能開発はほとんどしてないんですが・・いろんな CI サービスを使っている・使っていたのでそういう意味では参考になることもあるかもしれないです。）

今回 alpine イメージ上でのテストを今までしてなかったので、それを Dagger でやるようにしました。

ベースとなる cue ファイルはサンプルの todoapp を使いました。

1から書くよりもサンプルなどをベースに書いていくと楽だと思います。

なんですが、todoapp が参考にしたときと大分違う設定になっていました。
ちょうどそのころの Dagger 使った系の記事があったのでそちらを参考にしてください。
「ベンダーロックインしないCI/CDパイプライン、Daggerを使ってCodeCheckを自動化してみた。」

「コンテナベースのCI/CDツール「Dagger」を試してみよう - Qiita」

どういうふうに書いたかは百聞は一見に如かずということで、レポジトリを見てください。
この記事向けにコメントも追加してます。

https://github.com/srz-zumix/iutest/blob/develop/iutest.cue

とはいえ、見てくださいだけではこの記事の意味がないのでこの設定に至るまでの紆余曲折を記述しておきます。

変数展開は () でする

同じ設定はまとめたいので変数にしてたのですが、使うときに単純に変数を書くだけじゃだめでハマりました。

       // 必要な環境変数をセット
        env: {
            // string は () で囲んで展開する
            IUTEST_ROOT_DIR: (iutest_root_dir)
            // 文字列の中で変数展開する場合は ( をエスケープする
            IUTEST_OUTPUT_DIR: "\(test_result_dir)"
        }

exit: 0 は今の所意味がない

CTest が失敗しても後続の処理を継続したかったので終了コードを 0 に上書きしたいなーと思ったのですが、今はできないっぽい。
なので、しかたがないので script: contents の処理で失敗を無視してます。

always は condition の always ではない

↑と同じ理由で常に実行される処理を書きたかったので、always を使ってみたのですが、どうやらこれは実行条件の always とはちょっと違って、cache 利用するかしないかの always だったようです。
always を true にするとキャッシュを無視して常に実行されるようになりますが、依存処理が失敗していても実行するようなことはできませんでした。

https://docs.dagger.io/1231/always-execute/

常に実行したいってのは cache invalidate のことではないんだよなぁ・・

GitHub Actions で動かすには

dagger の cue ファイルを置いておいても、そのままでは CI サービスで実行されないので、各サービスでワークフローを書く必要があります。

GitHub Actions の場合は、dagger 用の action があるのでそれを使えばすぐに動かせます。

  dagger:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: dagger/dagger-for-github@v3
        with:
          cmds: |
            project init
            project update
            do ctest
    

CUE/Dagger を新たに覚えるのはつらい

ここから使ってみた感想なのですが、CUE が使いやすいかというとまだわからないのですが、少なくとも覚えることは多い印象。
YAML でのパイプライン記述における問題の１つである再利用性を CUE は解決していますが、最初に紹介した CUE を YAML のマージツールとして利用することで十分なような気もしますし、各 CI ツールで再利用性できる機能があったりしますし、Dagger である必要性があまり感じられませんでした。

より理解をするには CUE と Dagger の境界を認識して、それぞれで調べる力、検索力が必要になるかなと思いました。

ポータビリティについて

環境のポータビリティ

Dagger は「環境」のポータビリティを実現しています。

CI でもローカルでも同じ「環境」で処理を実行できます。

ローカルと CI で同じ「処理」をすることは Makefile でもなんでもいいですが、可能です。

なので CI と同じ「処理」をすることは Dagger を使わなくても可能です。
ただ、それだと実行環境は CI やローカルで異なるため、実行結果は変わってきます。
Dagger は実行環境もセットになっているので、同じ「環境」で同じ「処理」ができ、CI とローカルで同じ実行結果が期待できます。

これは大きなメリットです。仕事や個人開発でも CI でしか起きない問題の調査はめんどうです。ローカルで同じことができればこれも楽になります。
また、問題調査としてではなく開発者がローカルで動作確認をしたい場合に、ローカルで手軽に実行できるのも利点ですね。
私はゲーム開発に携わっているので、ターゲットプラットフォームでのビルドをローカルでしたいという需要はすごくわかります。（Dagger でゲーム開発のターゲットプラットフォームビルドができるかというと難しい気がしますが・・）

ただ、Dagger の実行環境はコンテナに制限されるため、コンテナでできないことはできません。
また、iutest はテスティングフレームワークなので、１つの同じ環境でテストするよりも、多様な環境でテストできたほうが嬉しいです。（※Dagger で複数環境用意するのもありですが、管理下の想定された環境よりも、管理外の環境のほうが意味があると思っている）

今回は alpine コンテナでのテストが今までなかったので Dagger を採用して GitHub Actions で動かしています（Dagger も環境の１つなので何かしらのテストを回しておきたいという意思）。

ワークフローのポータビリティ

ワークフロー？パイプライン？
言葉の定義があいまいなんですが、ここでは PR トリガーから結果の通知など CI の最初から最後までという意味合いでワークフローを使ってます。

「A PORTABLE DEVKIT FOR CI/CD PIPELINES」

Dagger のトップページにはこう書かれています。
パイプラインという言葉を使ってるので Dagger がカバーしている範囲はパイプラインと呼びます。

図にするとこんな感じかな。

Jenkins でジョブに直接処理を書かずに .sh ファイルとかにしようね。とか。ビルドツール使おうねとか。そららはパイプラインの話。

それのもう１つ上のレイヤーで環境とセットでまとめてくれるのが Dagger 。

さらに上のレイヤーであるワークフローはそれぞれ対応する必要がある。

Dagger はベンダー依存しない CI ツールという立ち位置ですが GitHub Actions での実行例を見ていただければ分かる通り、特定の CI サービス上で Dagger を実行するには Dagger だけでは完結しません。というか、GitHub Actions でいうとトリガー部分（on: pull_request）は Dagger では設定できませんし、動かす CI サービス固有の機能を使いたい場合は Dagger 外でやる必要があります。（Dagger はそういう CI の差を埋めてくれるものではないので）

そして CI サービスを引っ越しする場合には、トリガー周りなどそういった設定は書き直しになります。

CI/CD ワークフローのポータビリティという観点では、Dagger は直接的に貢献するわけではないです。（パイプライン部分だけでもポータブルになるので楽にはなる）

ただ、どのサービスを使うのか決まっているのであれば、そのサービスの書き方をしたほうが良いとも思えます。

逆に社内で使ってる CI サービスが多種多様であるとか、OSS だから手軽に乗り換えできると嬉しいとかであれば、Dagger を使う利点はあると思います。

ローカル実行について

実はローカル実行できる CI サービスもあります。
なので目的や事情によってはそのサービスのローカル実行機能を利用したほうがいい場合もあるかもしれません。

例えば CircleCI では cli からローカル実行できます。（制約はあります）

GitHub Actions の場合、nektos/act というツールを使えばエミュレートできます。（act は大分できないことや、Hosted runner との差異がありますが・・）

これらで十分なのであれば Dagger に置き換える必要はないと思います。
例えば、act は GitHub Actions のイベントをエミュレートしてくれるのでワークフローのローカル実行が可能ですが、Dagger は step レベルのローカル実行しかできないです。
このへんは使い分けでしょうね。

act のことは「ブログズミ: nektos/act で GitHub Actions のワークフローをローカル実行」と「GitHub Actions のローカル実行ツール（nektos/act）を便利にする gh extension を作った」で書いたのでよければ見て下さい。

まとめ

個人的には最近使ってみた Earthly の方が Dagger より使いやすいなと思いました。
Dagger がちょっと話題になりましたが、類似のツールと比較したり、今置かれている状況を踏まえて選択するのが良いと思いました。

以上、久しぶりに長めに書いた。ではでは。

CEDEC でやってた補助動詞の漢字・ら抜き言葉の検出を実装してみた

CEDEC 2022 の「AIによる自然言語処理を活用したゲームシナリオの誤字検出への取り組み」で誤字検出方法が解説されてました。
セッションタイトルにある AI の部分は BERT 使った誤字検出の話で、サクッと実装は難しそうなので、比較的簡単そうな「補助動詞の漢字」「ら抜き言葉」の検出を実装しました。

実はこのセッションは昨年の CEDEC 2021 の続編で、昨年の内容も一部検証実装してました。
そのときの記事はこちらです。
「CEDEC でやってた表記ゆれ検出をお試し実装してみた」

今回の実装は昨年書いた tails-of-words に機能追加として実装してます。
なんですが、昨年のアップデートかつ実装難度としても高くないのであまりここに書くことがありません。。
（どういうロジックなのかは割とまんまな記事が出るのでそちらか、おそらく CEDiL に資料公開されると思うのでそちらを見て下さい。）

ら抜き言葉検出の改良

強いて書くとすると「ら抜き言葉」の検出がセッションのとは少し異なるくらいですね。
セッションでは「ら抜き言葉」の誤検出の例として以下のテキストがでてました。

• 写真撮ってきたから見れ！
• あれ？あれれれ？
• 今こそ来たれ！

まず資料の通りに実装した場合の結果がこちら

なんだろなにもしなくても誤検知パターンを回避してるケースがあるな。前処理の違い？ pic.twitter.com/FEH4HTW2Wp

— ずみっくす（黄色） (@srz_zumix) September 4, 2022

なぜか1つ目と2つ目は「ら抜き言葉」とは判定されない解析結果でした（つまり誤検出しない）。

ツイートでは前処理の違いかもと言ってますが、 jumanpp に渡す前にテキストの正規化をしているのでもしかしてその違いがあるのかも？と思ったのですが、前処理で変化するような入力テキストではないので違いました。

使っている jumanpp or 辞書の違いでしょうか。（確認できないので、深追いはしない）

では、「今こそ来たれ！」ですが「れ」の直後の品詞が「特殊」となってます。
セッションで誤検出の例として上がったものすべて「特殊」品詞が直後にあるので、このパターンを「ら抜き言葉」から除外すれば良さそうです。

というわけで改良後はこうなります。

最後に

BERT とかそのへんもいつか触ってみたいです。

では。

nektos/act で GitHub Actions のワークフローをローカル実行

GitHub Actions で困る、というか面倒なのがワークフローのデバッグをするために都度 push してトライアンドエラーなところじゃないでしょうか？
単純に直列に step 並べるだけならそんなに困らないですが、steps.*.if 使ったり output 使って後続 step で利用しているような場合など、ちょっとしたミスで動かなかったりするのでできれば push するまえに確認できると嬉しいですよね。

あとはイベントによっては PR のときに確認できないことがあるので、マージしてからミスに気づくこともあります。
Release してみたらワークフロー失敗したってのは私も何回もやってます。そういう系は workflow_dispatch に対応しておくのがオススメ。

また、CI と同じことをローカルで実行したいということはよくあると思います。
CI サービスによってはローカル実行サポートしてることもありますが、GitHub Actions 公式には今の所ないので act を使います。

https://github.com/nektos/act

act pull_request とすると、 pull_request で trigger されるジョブが実行されます。
細かい使い方はドキュメント見ていただくとして、ここでは使ってみてわかった注意点などを書いておこうと思います。

最初に結論

最初にもっとも重要な注意点を書いておこうと思います。

act オススメしません！

補足すると「GitHub Actions と同じことをローカルでやりたい」のであれば act 使わずに Dagger とか Makefile とか shellscript とかなんでもいいので GitHub Actions のワークフローと処理を分離しておくことをおすすめします。
Jenkins のときと同じですね。

というわけでそのような目的がある場合は、この記事を読んでいないで処理の分離を始めましょう。

そうではなく、GitHub Actions のワークフローの方をローカルで検証したいときは act を使ってみるのはアリかもしれません。
記事の最後で私なりの利用ケースを考えてみたので興味のある方は最後までお付き合いいただけると幸いです。

ポイント

act の runner は hosted runner と同一ではない

act の runner は hosted runner よりも最小の環境で作られています。
なので hosted runner にはあるけど act の runner にはないものがあったりします。

より hosted runner に近いイメージも用意されていますが、とても大きいイメージなので注意してね、とのことです。
https://github.com/nektos/act#runners

↑にも書かれていますが、 -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04 のように runs-on 指定の名前を置換してあげることができます。
このオプションを利用すると self-hosted runner 使っている場合の対応が簡単です。

act のときは〜をする・〜をしない

https://github.com/nektos/act#skipping-steps

やはりどうしても環境が異なっていたり、act でできないこともあり、act でそのまんまワークフローを実行するのは無理だったりします。
なので、そういう場合は if: ${{ !env.ACT }} のように ACT 環境変数で分岐させると良いです。

コンテキストの内容がすべて定義されない

act pull_request としても github context にはほとんどの情報が設定されません。
特に event は空っぽなので、 github.event.pull_request.head.sha とかを workflow 中に参照していると失敗します。
イベント情報などある状態で act 実行したい場合は、以下に書かれてるようにイベントの json ファイルをオプションで指定してください。

https://github.com/nektos/act#events

GITHUB_TOKEN は自動発行されない

https://github.com/nektos/act#github_token

はい。当たり前ですが自動では発行されないです。必要な場合は -s オプション使ってシークレットをセットしてください。

サービスコンテナは未対応

services の内容は無視されます。

設定ファイル

act で実行するにはそれなりにオプションで動くようにカスタマイズが必要だと思います。
お試し程度なら良いかもしれませんが、開発ワークフローで act を常用するようであれば、それらの設定をファイル（.actrc）に書き出しておくと良いと思います。
こうしておけば誰でも実行できるようになるはず。

https://github.com/nektos/act#configuration

ドキュメントに書かれてないこと

本家とは微妙に挙動が異なることがある

これはほんの一例ですが、公式ツールではないのでどうしても本家と違う挙動をすることがあります。
※下記の例は旧バージョンの話なのですでに修正されてます。

そういえば act のバージョン古かったかもと思って更新したら、この問題は直ってた

Upgrading act
0.2.26 -> 0.2.29 https://t.co/hG7eWuxeJo

— ずみっくす (@srz_zumix) July 3, 2022

GitHub Actions は pull_request イベント時に存在しない github.event.head_commit.message を参照してもエラーにならないが、nektos/act だとエラーhttps://t.co/IuNrVZd9zI pic.twitter.com/Z1cGYYpz4S

— ずみっくす (@srz_zumix) July 2, 2022

setup-ruby が ImageOS が想定外のために失敗する

act の提供してる image の ImageOS 環境変数が small ってなってて ruby/setup-ruby が失敗しました。どうやら setup-ruby は ImageOS 環境変数で実行環境を判断してるっぽいです。
step.*.env で ImageOS 環境変数を与えて上げること回避することはできますが、act 向けの変数になってしまうので微妙ではあります。

こんなときに便利かも

シークレットを設定する権限をもっていないとき

そういうケースってあんまりない気もしますが、なくもないのかなと思います。
シークレットが必要なワークフローの PR をしたけど、そのリポジトリのシークレットを設定する権限がない。 fork したとか、リーダーにしか権限ないとか？

シークレット追加してもらって検証というのもしづらいかなと思いますので、act -s で想定シークレットを渡してデバッグしておくといいかもしれません。

レアなイベントをトリガーにしている場合

pull_request イベントなら PR 出せば済む話ですが、workflow_dispatch とか release とか branch_protection_rule とかのイベントトリガーのワークフローをデバッグするのってめんどくさいです。
というのもイベントによってはデフォルトブランチにワークフローがあることが条件のものがあるからです。
ワークフローをトリガーするイベント - GitHub Docs

こういうやつ。

ですが、act 使えばこれらのイベントでトリガーされたときのデバッグが簡単になると思います。（env.ACT をみて dryrun な状態にしておくこと！）

最後に

act どうなんでしょうね？
本当に必要なケースってあんまりないような気もしてしまいます。

GitHub Actions のワークフローで書くことって大概が pull_request イベントだと思うし、それなら実際に動かしたらいいってなるし。

時間かかるからローカルがいい、処理をデバッグしたいって話だとワークフローとは別の話な気がするので act でなくても解決できるはず。

デフォルトブランチに入れなきゃ動作確認できないイベントはたしかに act があると便利そうではありますが・・果たして本当に楽になるのだろうか？

「デフォルトブランチに入れなきゃ確認できない」って部分は GitHub 公式でなんらか解決策を出してくれると嬉しいですね。

以上。

Git で今のブランチ名を取得するコマンドの違いを確認してみた

Git で今いるブランチ名を確認する方法はいくつかあります。
そういう情報は検索すればいっぱい出てきますが、今回は以下の 4 つを比較しました。

git コマンドの出力を加工する方法も検索すると出てきますが、加工なんかしなくても取れるのでそういう系は今回は除外。

* git branch --show-current

* git rev-parse --abbrev-ref HEAD

* git symbolic-ref --short HEAD

* git name-rev --name-only HEAD

とりあえず、試すとこうです。

ただ単にコマンドを実行しただけではどれも同じに見えます。
以下で細かく確認をしていきます。
（本記事執筆時の筆者環境の git version は 2.37.1）

内部処理

まずは、GIT_TRACE で内部的に何をしているのかの違いを確認してみます。
GIT_TRACE は git コマンドのデバッグ用変数です。git コマンドが遅いとか挙動調べるのに使えるので覚えておくと便利です。

こちらもどれも built-in の呼び出しのみで差分なし。
ちなみにこれだと GIT_TRACE の挙動が分かりづらいので git fetch のトレースを貼っておきます。（実は git fetch が中どんな処理をしているのかが伺えます）

パフォーマンス

次は、パフォーマンスの比較をします。GIT_TRACE_PERFORMANCE で内部処理の各処理のパフォーマンスを出力できますが、今回はコマンド自体のパフォーマンスを比較したいのでベンチマーク用のツールを使用します。

今回は hyperfine を使いました。また計測環境は alpine コンテナ内にコピーしたリポジトリで行いました。（コンテナ内の git version は 2.36.2）

結果はこちら

name-rev を使ったものだけ少し遅い結果となりました。他は大体同じくらい。

バージョン

最後に各コマンドが使える Git のバージョンを確認しておきます。
比較的新しいサブコマンドやオプションだと古い環境では使えない可能性もあるので、選択する際の参考になると思います。

command	version
git branch --show-current	2.20
git rev-parse --abbrev-ref HEAD	1.6.3
git symbolic-ref --short HEAD	1.7.10
git name-rev --name-only HEAD	1.5.3

--show-current が比較的新しめの機能でした。
他は今の最新バージョンが 2.37 なのを考えると誤差と言えると思います。

Detached

もう１個だけ確認して置きたいことがありました。 CI などでは Detached 状態で checkout されることがあるので、その場合の挙動を確認しておきましょう。

ここで大きな違いがでてきましたね。
表にまとめるとこうです。

command	出力	exit code
git branch --show-current		0
git rev-parse --abbrev-ref HEAD	HEAD	0
git symbolic-ref --short HEAD	fatal: ref HEAD is not a symbolic ref	128
git name-rev --name-only HEAD	ブランチ名	0

symbolic-ref だとコマンドが失敗します。他はそれぞれ出力結果が違いますが、ブランチ名が取れるのは name-rev のみでした。name-rev がちょっと他より遅い理由がなんとなくわかりますね。

CI とかでも fetch はされてるはずなので name-rev ならブランチ名を取得できそうです。
（pull_request の場合は merge ブランチになってるので注意）

また、例えば１つ前のコミットを指してた場合は以下のように ~ 使った表現で出力される模様。

あと、Detached 状態からコミットしてどこのブランチにもいないような場合は「undefined」が出力されます。

まとめ

Detached 状態のときにどうするかで使うコマンドを選ぶと良さそうです。
ブランチ名を必ず取りたいなら name-rev を使うことになります。
Detached が稀で速度を気にするのであれば↓のように symbolic-ref を最初に試みるのがいいかもしれません。

git symbolic-ref --short HEAD 2>/dev/null || git name-rev --name-only HEAD

なんらかの文字列が入っていればよいのであれば rev-parse 、逆に空文字が良ければ branch --show-current ですね。--show-current が git version 2.20 以降でしか使えないのでそこは注意してください。（あとは --show-current の Detached 状態の挙動はバグの可能性もあるので、今後挙動が変わるかもしれません）

調べ始めたときは、対して違いはありませんでしたーってオチを予想してたのですが、割と調べてみてよかったなと思いました。

では。

GitHub Actions の Composite Action で post 処理を実現する方法

GitHub Actions での処理の共有方法として action がありますが、現在この action は javascript と docker そして composite の  3  つの方法で作成することができます。
筆者は今から action 作るなら composite をおすすめします。
composite action は登場した当初は runs.steps[*].if や runs.steps[*].uses が使えなかったので、ちょっと力不足でしたが最新のバージョンであればこれらが使えるようになっており、action を作る上で困ることはほとんどなくなったと思います。

じゃあ、タイトルはなんなんだということになりますが、ちょっと凝ったことしようと思うと（他ではできるけど） composite ではできないこともあります。

それがタイトルに書いた post 処理です。
右のスクリーンショットは action に書ける Metadata syntax なのですが、composite だけ post に対応してません。（詳細はリンク先へ）

でも、大丈夫です。というのがこの記事。
いずれ公式で composite action にも post が対応されると思いますが、今の状態でも post 処理できます。

その前に。
post 処理とはどんなものかと言うと、ジョブのステップが全部終わった後に行う処理のことです。みなさんがよく使うであろう actions/checkout でも post 処理が行われています。

こんな感じ。
基本的には action で設定したものをもとに戻したり、docker コンテナを停止したりするのに利用されています。

では本題です。
composite action で post 処理を行うには・・・
「post 処理ができる action を uses で呼び出す」ことで可能です！

つまり、「composite action は uses で他の action を呼び出せるので、javascript/docker action を呼べば良い」のです。

リポジトリが別になっちゃう？
いえ、大丈夫。 uses は相対パスで action を呼び出せます。

つまりこういうことです。

composite action の repository のサブディレクトリに javascript/docker action を配置して、それを composite action から呼び出し、呼び出した action の post 処理を composite action の post 処理の代わりにします。
「uses: "./resources/post-action"」 がその部分で、この action のメイン処理は空で、post 処理で起動したコンテナの終了をしています。

実際にこの書き方をした action のリポジトリはこちら。
https://github.com/srz-zumix/setup-service-jenkins

composite ではない action を使うことになるので、それはそれで問題があったりしますがネストされた action なので実はそのへんもなんとかなっちゃうかもしれないなと思ってます。（javascript action の default node version 問題とか）
（docker action は実行できない os があるので、この目的ではあまりオススメしません）

ざつにざーっと書きましたが、今回は以上となります。では。

Slack の過去の投稿を再投稿して 90 日制限を回避する

えっと。はじめに断っておきますが、ネタ記事です。

Slack が 90 日前までしか見えなくなったので、だったら期日前のメッセージを再投稿したれと作ったシナリオ。
N 日前のメッセージを検索してスレッドに投稿し直します。 pic.twitter.com/a57yGVGgzq

— ずみっくす (@srz_zumix) July 23, 2022

「Slack 初の料金改定とフリープランの内容変更のお知らせ | Slack」

Slack の改定により、フリープランでは 90 日間の履歴しか閲覧できなくなりました。
この変更は結構困っている人は多そうで、Twitter などでもちょこちょこつぶやいている人を見かけました。
これを機に Slack から別ツールへ移行する人も多いようですが、私は今現在は主に通知用として使っているだけなので、特になにもせずに使い続けようと思ってます。
ただ、メモ置きとして使っていたような気もするので、実はそのうち困るかもしれません。。

そこでひらめきました！（のび太の画像）
90 日前までの履歴しか見えないのであれば、見えなくなる前に投稿し直せばいいのでは？

というわけでサクッと Make formary Integromat でシナリオ書いてみたのが冒頭のツイート。
ネタだけどちょこっと解説していきます。Integormat についてはこのブログでも何度か書いてるのでそのへんを参考にしてください。

シナリオ解説

概要

処理の流れは大体こんな感じ。トリガーは一日一回。

1. 検索日（現在時刻から指定日数前の YYYY-MM-DD）と検索チャンネルの変数をセット
2. Slack Search モジュールで検索
3. 一度バンドルを集計（ホントはここで filter かけて集計したかった）
4. 再投稿用のスレッドの親メッセージを投稿
5. 集計したバンドル配列で以下の処理を各要素繰り返し
1. 投稿ユーザー情報を取得（ユーザーのアイコンつけたかっただけ）
2. 検索したメッセージとユーザー情報を使って、内容を再投稿

5 の前に検索結果が空でないかのフィルターをセットしてます。

また 6.1 の前にユーザー情報が取得可能でフィルターをセットしてます。

検索結果のバンドルをそのまま流して再投稿することも可能ですが、スレッドにしたかったので一度集計してバンドルを１つにしてます。（Integromat はモジュールの output バンドルの数だけ以降のシナリオが実行される仕組みです。集計してバンドルを１つにすることで、スレッドの親メッセージの投稿処理を１回だけにしてます。）

関係ないけど Slack の Block Kit Builder を初めて使いました。便利でした。

Blue print

Integromat は Blue print でシナリオの export/import が可能なので Gist に置いておきました。これを見る、もしくは import してもらって見たほうが理解しやすいと思います。

補足

• Blue print の connection は筆者の Integromat のものなのでそのままでは使えません。もし import したら conection を更新してください。
• 今回のシナリオは Twitter モジュール使ってないので Integromat のフリープランの範囲で使えます。
• ただし、そこそこオペレーター数を使うシナリオ、かつ Slack のメッセージごとに消費するので、メッセージが多いと Integromat のフリープランを超えてしまします。
  Pricing & Subscription Packages | Make
  ざっくり計算で１日あたり 7 件のメッセージを処理するのが限界じゃないかなーと思います。
  動作優先でオペレーターの最適化してないのでもっと減らせる（※）とは思いますが、仮に不可能ではありますが 1 オペレーターでシナリオが書けたとしても、Integromat のフリープランの最大 1,000 件は越えられないです。
  （※スレッドやめるとかアイコンやめるとか、１週間分まとめて処理するとか）
  
• あと再投稿したスレッドがまた期日を迎えたときにどうなるかとか、ボットどうするかとか、添付ファイルとか、いろいろ確認してないので、ちゃんとやりたい人は頑張ってください。

（期日内であれば）件数無制限という点について

これは Slack からのお知らせのスクリーンショットです。

変更前だと直近 10,000 件しか閲覧できてなかったのですが、今回の改定で期日以内であればこの件数制限がなくなったようです。
（この記事書いてて気づいたレベルなので自分は困ってなかったみたいだ）

さて、もうお気づきかと思いますが、実は紹介した方法を使うとなんと！日数制限も超えてメッセージを無限に扱えるようになっちゃいます！

やってることは検索して再投稿なので Slack API 叩けば誰でもどこでも出来ちゃいます。GitHub Actions とかでやらせることもできちゃうと思います。（それなら Integromat とかの RPA よりも無料の範囲でできそう）

つまり（使いやすいかどうかは置いておいて）実質無制限になったわけですw

いやー、私はまぁそこまでして使おうと思いませんが。。

（でもこれ書いてて思ったけどファイルストレージは意外と？）

最後に

90日間を永遠に繰り返す Slack という空間に閉じ込められた俺達は・・

— ずみっくす (@srz_zumix) July 23, 2022

なんか書けそうな気がする。。

Integromat migrate to Make (formerly Integromat)

Integromat は新しいサービスの Make に生まれ変わりました。
Integromat のサポートは 2023 年に終了するとこのことなので、そろそろ移行したいと思います。

この記事はその作業ログです。

はじめに

なんで Make って名前にしたのかな？めちゃくちゃ検索しづらい名前で最低。
ロゴはそのうち変わるのかもしれないけど、Make formerly Integromat って書いちゃってるし！

make (formerly integromat)
integromat のままで良かったのでは？ pic.twitter.com/gzIYHDkmpY

— ずみっくす (@srz_zumix) July 3, 2022

サービスとしてどうかわったのかとか全く見てないので Integromat より Make のほうが優れてて素晴らしいのかもしれないけど、名前だけはダメだ。

。。。

まぁ名前はともあれ移行していきます。
ちなみにこのブログでは今後 Make formerly Integromat を正式名とし、略称として Make と呼びます。
（単に Make だとややこしすぎるので、タイトルとかには略称さける。。。）

Pricing

と、その前に料金プランを比較しておきましょう。

https://www.make.com/en/pricing

価格帯はほぼほぼ同じですが、Integromat は $9/月 でしたが、Make の場合年間払いで同じ $9/月 になります。単月だと $10.59/月。

BASIC と Core プランを比較してみました。

表記載のもの以外にも違いはありますが、Make のほうが全体的に条件が良くなっているので嬉しいですね。

移行前の注意点

移行後の Integromat

Make に移行後の Integromat Oraganization は readonly mode に設定され、シナリオの作成・編集・有効化などができないので注意してください。
筆者の場合、移行時に Integromat 側のシナリオを無効、Make に移行したシナリオを有効にする設定で Migrate したため、readonly mode になっているのかもしれません。

支払情報

Make に先に SignUp して支払情報の登録まで済ませてしまうと、移行後の処理に時間がかかるそうです。支払情報の登録は Integromat から移行後にしたほうが良さそうです。

手順書

公式に手順書があるのでそれに沿って移行していきましょう。
Integromat には Blueprint という形式で import/export できましたが、それでの migrate は非推奨らしいです。こちらの手順書に従って Migration tool を使うことが推奨されています。

1. Before you start

まずは移行作業前の注意点です。

Make のアカウントが必要になります。先に作ってもいいけど Upgrade hub でもできるらしいので Upgrade hub にまかせようと思います。

次に Make に組織（Organization）とチームが最低１つは必要になるそうです。
これも Upgrade hub でできるらしいのでおまかせ。

次、エラーがあるシナリオは移行できない。
しばらく動かしてないシナリオとかあるのでそのへんどうなるのだろう？
エラーはおそらく実行時のエラーではなく、下のようなシナリオのエラーのことだと思うので多分大丈夫だと思いますが、とりあえず何もせずにやってみる。

Make では Webhook や Mailhook は1つにつき1シナリオの制約になったそうです。
Integromat では1つの Webhook で複数のシナリオをトリガーできてましたが、そのようなシナリオは Upgrade hub では移行されないようです。
移行したい場合は各シナリオごとに Webhook を用意するようにしましょう。

最後にサービスが変わったことで IP も変わるので IP 制限かかっているサービスと連携している場合は注意が必要です。
例えば社内サービスで Integromat を許可IPに入れてた場合は更新が必要ですね。
自分は個人的に使ってるだけで、そういったサービスはないので気にしなくてよさそうです。

注意点は以上。確認して問題なさそうであれば「Let's start」で次に進みます。

2. Login to accounts

Source に Integromat Legacy を選択、Target は Make 。
それぞれ「Sign in to source/target」があるので Sign in します。

クリックするとポップアップが出るのでアカウントを選択します。

結局ここで Make のアカウントは作ることになります。

アカウント作ると組織（Organization）の作成画面でてきます。
移行する組織を選択してください。私の場合は有料アカウントの組織と無料アカウントの組織を使い分けていたので2つありますが、まずは有料アカウントの方を移行しました。

region を EU/US のどちらにするか選べますが、なんとなく GDPR のことが気になったので US にしました（US は US で CCPA とかあるけど）（JP 選べると気軽でいいんですけどね）

「Begin upgrade」ボタンを押すとポップアップウィンドウの中で Upgrade hub の続きが始まるってるので一回閉じてしまって良いです。もう一度「Sign in to target」で Make に Sign in しアカウントを選択してください。
（※ Make に Sign up したときに Integromat に Sign in 済みだったので Upgrade が始まったんだと思います）

もとの画面でアカウントを選択すると次に進めるようになります。

2.1 Teams & organizations

（Make に Sign up した際に Organization を作ってしまったので、作らなかった場合にどうなっていたのかはわかりませんが）Source / Target ともに Organization を選択する画面が出てきます。
Make のほうには Team もありますが、まだ特になにもしてないのでデフォルトのものを選択しておきます。

選択したら次へ進みます。

3. Data selection

3.2 Collision detection

1つの Webhook を2つのシナリオで使用していたため、修正もしくはスキップを選択する画面が出てきました。
こちら 3.2 となっていますが、筆者の場合 3.1 が出てきませんでした。
おそらくエラーのあるシナリオがあると 3.1 で同じようにどうするか対応を要求されたのだと思います。

今回は単純にバージョンアップ時に別シナリオにしていただけなので最新のシナリオだけ移行させました。

3.3 Scenarios

移行するシナリオを選択します。
特に理由がなければ Select all でいいと思います。

「Migrate manually」と「Fast migration」があります。
Upgrading to Make によれば複雑なシナリオがあると自動では無理らしく、そういうシナリオがあると手動 migrate が出てくるらしいです。（単純なシナリオだけだと出てこない？or manually が濃色で表示される？）

3.4 Data selection（Migrate manually を選択した場合）

3.3 で「Migrate manually」を選択するとまずは Webhook の移行方法の選択画面が開きます。

「Duplicate webhook」と「Duplicate webhook and forward traffic」がありますが、どちらも Make で新しい webhook が作成され、それが使用されます。後者の場合は Source （Integromat）側の Webhook そのままで Make のシナリオをトリガーできます。
なので、後者であれば Webhook を使ってる側は変更不要です。
ただし、Integromat のサービス終了とともに使えなくなるので、早めに新しい Webhook URL に移行しましょう。

「Next」にいくと connection 系の移行方法選択になります。

筆者の場合は特に移行方法を選択するものはありませんでした。

「Next」にいくと Key の移行方法選択になります。 

こちらも筆者の場合は特に選択肢はありませんでした。

「Next」にいくと Data store の移行方法選択になります。 

こちらは「Duplicate data store and migrate contents」と「Duplicate data store without contents」が選べます。
前者は Data store とその中身も複製します。後者は Data store だけで中身のデータは複製されません（空の Data store になります）。筆者は、ちょうど中身消したい Data store があったのでそれだけ後者を選択しました。

「Next」にいくと Data structure の移行方法選択になります。 

こちらも筆者の場合は特に選択肢はありませんでした。

「Next」にいくと Folder の移行方法選択になります。

こちらも筆者の場合は特に選択肢はありませんでした。

「Next」にいくと 4.1 Migration settings へ進みます。

3.4 Data selection（Fast migration を選択した場合）

3.3 で「Fast migration」を選択するとデバイスの移行方法の選択が出ます。
「Fast migration」だと設定はこれのみでした。
「Next」にいくと 4.2 Migration settings へ進みます。

4. Migration process

4.1 Migration settings

移行後のシナリオをどうするかを Source/Target で決めます。
デフォルトだと Source 側（Integromat）のシナリオを無効化、 Target 側（Make）のシナリオ（Active なもののみ）有効化します。

とりあえず設定だけ移行して、実行はおいおい切り替えていくのであれば変更しましょう。

4.2 Migration settings

これで Migration の設定は完了です。「Start migration」をクリックすると移行処理が始まります。

少し待てば移行が終わります。そんなに時間かかりませんでした。
以下のように移行結果が表示されます。

「Go to target」で Make を開くと以下のような画面が出ます。

これで移行完了です。お疲れ様でした。

支払情報の移行

Integromat を無料で使っていた方は以降の対応は不要です。
筆者は有料でも使っていたので、Integromat に支払った分を Make でも使えるようになっていました。
（月末にやればよかったなと思いつつ、ちゃんとサポートされててよかった）
（Integromat の使用量 + Make の使用量になってる？）
（Integromat で繰越した Operations は Make には移らない？）

ただし、支払い情報は移行されていないため、翌月以降の支払いは Integromat で引き続き行われます。Integromat が終了すると支払いが止まるため、継続利用する場合は Make に支払情報を登録しましょう。

最後に

Make に移行したシナリオが元気に動き出しました。

ちゃんと動いてる pic.twitter.com/U7az8VgcaG

— ずみっくす (@srz_zumix) July 5, 2022

今の所移行でのトラブルはありません。
今回は以上。ではでは。