ブログズミ: 4月 2021

2021年4月26日月曜日

CircleCI でモノレポ上の指定パスに変更があったらテストを走らせる

「GitHub Actions でモノレポ上の変更があったプロジェクトだけテストを走らせる」
これを読んで、

ちなみに書きかけだけど paths みたいなパスでトリガーをフィルターできるかどうかはここでまとめてる。https://t.co/QtlDVDQI4B
— ずみっくす@あつまれCIサービス (@srz_zumix) April 22, 2021

からの

ぜひぜひお試しのほど、よろしくお願いいたします！https://t.co/XblLXJaVvR
— CircleCI Japan (@CircleCIJapan) April 23, 2021

これで、公式から記事も紹介してもらったのでやってみた。

Setup Wrokflows とは

現在 OpenPreview 中の機能です。
最初に読み込む config.yml がセットアップワークフローになって、後続のワークフローを動的に構築できる感じですかね。
その１つの使い方として、変更があったパスごとに実行するワークフローを変えるとかができるってことですね。
使い方は公式記事を見ると良いと思いますが、こちらでも簡単に手順を追ってみます。

「セットアップ・ワークフロー(モノレポ対応) プレビューに参加しよう！(setup workflow) - Community - CircleCI Discuss」

「Setup Workflows Open Preview - Announcements - CircleCI Discuss」

「Project Settings」の「Advanced」にある「Run Setup Workflows (PREVIEW)」を有効にする
config.yml に「setup: true」を足すとセットアップワークフローになります
あとは、もともと config.yml にあったワークフローを別ファイルにし、config.yml にはセットアップワークフローを書く感じになります。

試してみた

実際にやってみないとわからないので、タイトルに書いたとおりパスフィルターを設定して特定のワークフローを実行させてみました。
パスフィルターには「Path filtering Orb」が必要になります。使い方はリンク先もしくは、試してみたリポジトリの YAML を見ればわかると思いますが、こちらでも説明していきます。

https://github.com/srz-zumix/ci-trigger/pull/15

まずはもともとあった config.yml を別ファイルにリネームします。
これはセットアップワークフローから呼び出すファイルになります。

次に config.yml を以下のように書きます。

version: '2.1'
# Enable the Setup Workflows setting to true (it is under “Advanced” in the project settings)
setup: true

orbs:
  path-filtering: circleci/path-filtering@0.0.1

workflows:
  generate-config:
    jobs:
      - path-filtering/filter:
          base-revision: master
          config-path: .circleci/path-filtered-config1.yml
          mapping: |
            .circleci/.* build-pipeline true
            README.md build-docs true

      # https://twitter.com/srz_zumix/status/1385426925531762691
      # {"message":"Pipeline is not in setup state."}
      # - path-filtering/filter:
      #     base-revision: master
      #     config-path: .circleci/path-filtered-config2.yml
      #     mapping: |
      #       .circleci/.* build-pipeline true
      #       README.md build-docs true

「setup: true」を忘れると怒られます。

> CIRCLE_CONTINUATION_KEY is required. Make sure setup workflows are enabled.

はて？
— ずみっくす@あつまれCIサービス (@srz_zumix) April 23, 2021

config-path にはリネームした config.yml を書く感じになると思います。ここに指定した YAML に定義されたワークフローをパラメーター付きで実行することになります。
mapping にパスフィルター（正規表現）とフィルターマッチしたときに付与するパラメーターを指定します。
↑の例では .circleci/ 以下のファイルに変更があったときに「build-pipeline: true」
README.md に変更があったときには「build-docs: true」が与えられます。
（base-revision は差分の比較対象になるブランチ名です。今回は master としてますが、PR の場合は base branch にしたくなる気がしてます。こちらは課題として引き続き検証したいと思います。）

最後に呼び出される YAML にパラメーターの定義とワークフローの when で条件付けします。
パラメーター定義

version: 2.1
parameters:
  build-docs:
    type: boolean
    default: false
  build-pipeline:
    type: boolean
    default: false
  build-other:
    type: boolean
    default: false

条件付け

workflows:
  build-docs:
    when: << pipeline.parameters.build-docs >>
    jobs:
      - build
  build-pipeline:
    when: << pipeline.parameters.build-pipeline >>
    jobs:
      - build
  build-other:
    when: << pipeline.parameters.build-other >>
    jobs:
      - build

こちらの実行結果が↓です。
セットアップジョブには「SETUP」ってついてますね。
この PR には .circleci/.* と README.md どちらも差分があるので、セットアップの実行後に、 build が pipeline/docs の分の2つが実行されました。（other は実行されない）

また、README.md だけの更新 PR の場合は↓です。

ちゃんと build-docs だけの実行になってますね！

ちなみにセットアップジョブを複数書いたらどうなるかも試しました。
↑の config.yml のコメントを外して試してみたのですが、エラーで片方しか実行できませんでした。

> {"message":"Pipeline is not in setup state."}
うーん、2個はダメか？ pic.twitter.com/Df2s64sE1W
— ずみっくす@あつまれCIサービス (@srz_zumix) April 23, 2021

こちらは自分の書き方が悪いだけかもしれませんが、追い検証はのちのち。。

最後に

CircleCI がどんどん便利になっていくなーと感じました。
今回はパスフィルターを使って、パラメーターから when で実行するワークフローを on/off させましたが、パラメーターは step 型も扱えちゃうので複雑な制御もいろいろできそうだなと思いました。

セットアップワークフローはまだ Preview 状態なので、引き続きウォッチしていきたいと思います。では。

2021年4月21日水曜日

docker build ログを今まで通りに表示する

docker build したときの出力がなんかいい感じにまとめられてコンパクトになりましたね。

でも、RUN した出力を知りたいんじゃ！ってこともあります。
そんなときは docker build --progress=plain で OK

2021年4月13日火曜日

Jinja2 cli な kamidana の additonals として slack 拡張を書いてみた

Jinja2 は python のテンプレートエンジンです。
そして kamidana は Jinja2 の CLI です。
今回はふと思い立って Jinja2 で API 叩いてそのレスポンスを加工したいなーと思い、その練習の１つとして slack API を叩いてみました。

kamidana には --additionals オプションがあり、 .py ファイルを指定するとフィルターなどを拡張することができます。
最初は自分で Jinja2 組み込みで cli 書こうと思ってたんですが、↓を読んで additionals が便利そうだったので、この構成にしました。
悩んだ末に自分で自分の使うツールを作った話 - Qiitaできたもの

https://github.com/srz-zumix/yurumikuji

Slack = ゆとり・ゆるみ
Jinja2 = 神社
kamidana = 神棚
ということで、「ゆるみくじ」という名前にしました。
（ゆるみくじは干支などの動物の形したおみくじとか、ちょっとかわいいおみくじのことを指すみたいです。知らんかった）

実装したのはユーザー・ユーザーグループの情報取得と検索フィルターです。
使い方はリポジトリの README を読んでもらうとして・・・
例えば以下のテンプレートファイルを kamidana で処理すると

{{ ("srz_zumix" | slack_user_id | slack_user_info).profile.image_512 }}
{{ ("srz_zumix" | slack_user_id | slack_user_profile).image_512 }}
{{ "srz_zumix" | slack_user_id | slack_user_presence }}

このようになります。

https://secure.gravatar.com/avatar/a7614593f3f6f46b73da348c89beba81.jpg?s=512&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-512.png
https://secure.gravatar.com/avatar/a7614593f3f6f46b73da348c89beba81.jpg?s=512&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-512.png
active

書いてみた感想

使ってみると何に使えるかわかんないけど面白い。
レスポンスをそのまま返してるだけだけど、 Jinja2 の基本的な書き方で必要なものにアクセスできるので可能性を感じました。

とりあえず、しょっちゅう変わる所属を Slack のカスタムフィールドから取ってきて、メール署名のテンプレートでも作ってみようと思います。
あとは、本当にやりたかったことも簡単にできそうなことがわかったので kamidana additionals でやろうと思います。

では。

2021年4月6日火曜日

【Ruboty】Slack のリアクションに反応できるようにするプラグインを公開

Ruboty で Slack のリアクション（スタンプ）に反応するハンドラーを書けるようにするプラグインを作成し、公開しました。
https://github.com/srz-zumix/ruboty-slack_reaction_added
https://rubygems.org/gems/ruboty-slack_reaction_added
なんかボットに対してコマンドを投げるのも面倒くさいし覚えきれない、「あとでやる」「TODO」「メモ」とかリアクションをしつつ忘れてしまったり、ということがあったのでリアクションをトリガーになんかアクションできたら便利だよなーと思って書きました。

サンプル

ruboty-slack_reaction_added を追加するとデフォルトのアクションが有効になります。
リアクションにも反応をする ping => @bot reaction ping
リアクションの名前を教えてくれる => @bot reaction name
bookmark リアクションをすると parmalink を教えてくれる (all)
+1 リアクションするとボットも +1 してくれる (all)

ハンドラーの書き方

ruboty-slack_reaction_added で使えるようになるハンドラーのオプションは２つです。

allow_reaction

allow_reaction: true にすると、リアクションに対してもそのアクションが実行されるようになります。

        on /reaction ping\z/,
          name: 'reaction_able_ping',
          description: 'ping allow reaction',
          allow_reaction: true

raction_only

raction_only: true にすると、リアクションした場合のみそのアクションが実行されるようになります。ただのメッセージ投稿には反応しません。

        on /.*\z/m,
          name: 'thumbup',
          description: 'thumbup',
          reaction_only: true,
          all: true

リアクション情報のとり方

アクションでなんのリアクションをしたのか場合分けしたい場合は、message から取得してください。また、誰がリアクションしたのかも取れるようになっています。

        def call
          # Ruboty.logger.info message.reaction
          # Ruboty.logger.info message.reaction_by
          unless message.reaction_by == message.robot.name
            case message.reaction
            when '+1'
              message.add_reaction('thumbsup')
            end
          end
        end

ハンドラーのほうでリアクション名/ユーザー名で条件づけできるようにしても良かったのですが、面倒くさかったのでやめました

デフォルトアクションを無効にする

ruboty-slack_reaction_added デフォルトアクションを無効にしたい場合は、環境変数に「DISABLE_DEFAULT_REACTION_HANDLERS=1」を設定してください。

最後に

結構便利なものができた気がする。

2021年4月3日土曜日

ウマ娘にハマってしまっていた

最近、ブログ執筆ペースが落ちてるのですが
「ウマ娘」にハマってしまっていました。
中高生のときにパワプロにドハマリしてたころを思い出しますね。

今まであまりおおっぴらにはしてこなかったのですが、
自分がプレイしてるゲームの「自動化」を趣味でやってて、
Airtest 使った UI オートメーションだったり、RPA 使った通知システムだったり、
そんなのを作ってます。

ウマ娘では「ハルウララ金策」自動化をしました。
育成開始から目標失敗で終わるまで自動で進めてくれます。
テキトーに組んだシナリオですが、それなりに確度高くできてると思いますね。
（記者の吹き出しの色がミドリで、たまに選択肢のミドリと誤認識してたのを気をつけたくらい）

「ハルウララ金策」は見るに堪えない作業ですが、自動化すれば心も痛みません！（え
（実際には TP 足らなくてほとんど出番はないですが…）

Airtest 使えば誰でも簡単にできちゃうと思いますが、
この手のツールを使った自動化は BAN 対象になりうるので自己責任でお願いします。
では。

登録: 投稿 (Atom)

ブログズミ

ページ