ちょっと込み入った使い方をする場合には act はつらいという印象です
- CircleCI には YAML のバリデータがある*1ので、それについては CircleCI が便利
- act は厳密なチェックをしてくれるという意味では有用でもあるし不便でもある
  - 例えば、特定の on: でしか使用しない {{ github.foo.bar }} を共通のジョブに組み込んでいるとき、それが定義されてないというエラーが出る
- 一方で act では一部の記述が誤判定？される
  - 例えば、run: | 内で # で実行行をコメントアウトするとエラー*2になる（シェルスクリプトのコメントアウトなのでエラー出してほしくない）
いずれにしろ archive.ubuntu.com 遠い（遅い）問題がついてまわります
GitHub Actions については将来的に gh コマンドに組み込まれそうな予感はします

補足

ローカルで実行する意義というのは以下になるかなと思います。

CI の無料利用時間を消費したくない
CI の実行テストのためのコミットを積みたくない・見せたくない*3

「1.」についてはプライベートリポジトリのみの話なので*4、プライベートリポジトリにした上で無料時間の消費を気にするならば素直に💴で叩くべきだとは思います*5。

あるいは「セルフホストランナー」をサクッと立てるのもよいと思います（これ自体は無料です）。GitHub 側としてはローカル実行するならばこの選択肢を選んでもらいたいのではないかと想像しています*6。

「2.」については……まあそういうときはあるのですが、たとえばセンシティブな情報を直書きとかしないのならば、後からsquashする前提でコミットメッセージに「CI のテスト中」であることをそれっぽく書いていれば見る人も察してくれるんじゃないかなと思います。

ローカルの実行では遅すぎたりマシンリソースを持っていかれないようにしたりするために SaaS を使っているので、そのメリットを享受しない理由としては弱いんじゃないかなと思っています*7。

そしてローカルだととにかく apt が遅いのがつらい*8。

参考

zenn.dev

*1:$ circleci config validate

*2:Unable to interpolate string

*3:あとで squash することは前提です

*4:パブリックリポジトリの場合、GitHub Actions は実行上限なし、CircleCI の場合は使い切れないぐらいの無料時間が追加される

*5:特に業務利用の場合

*6:リポジトリごとに設定するのが面倒ですが……

*7:トライアンドエラーを回すスピードというのは開発速度や開発体験、モチベーションに直結すると思います

*8:npm や rubygems も遅い

2021-09-27

Cypress で対象セレクタが複数ある中から任意のセレクタを選ぶ方法とその際の注意点

プログラミング -> 言語 -> JavaScript ソフトウェア開発

結論

cy.get('.foobar').eq(3) のように、get したあとに eq で取得できる
注意点として、get の戻り値を変数に格納している場合、eq を実行してしまうと格納した変数のオブジェクトは変更される
- シャローコピーになるということ

具体例

以下のような HTML があったとします。

<html>
  <head></head>
  <body>
    <div class="foobar">1</div>
    <div class="foobar">2</div>
    <div class="foobar">3</div>
    <div class="foobar">4</div>
    <div class="foobar">5</div>
  </body>
</html>

4つ目のセレクタを得たい場合には次のように get してから eq で取得します。

cy.get('.foobar').eq(3)

注意点

1. selectors

上記の例において、5つのセレクタのオブジェクトを以下のように selectors に格納したとします。

const selectors = cy.get('.foobar')

この個数をチェックすると、確かに5つです。

selectors.should('have.length', 5) // true

2. selectors.eq

ここで例えば3つ目のセレクタを抽出するために selectors に対して eq メソッドを以下のように実行したとします。

const thirdSelector = selectors.eq(2)

この後に selectors の個数をチェックすると「1つ」になっています（「5つ」ではない）。

selectors.should('have.length', 5) // false

3. エラーメッセージ

エラーメッセージは次のとおりです。

AssertionError: Timed out retrying after 4000ms: Not enough elements found. Found '1', expected '5'.
+ expected - actual

-1
+5

4. その他の場合でもエラーが出ることがある

上記の場合以外でもエラーが出ることがあります*1。したがって、無用なハマりを防ぐためにも変数に格納することは控えたほうがいいでしょう。

補足

as を使うべき、という意味でもあるのでしょう。

docs.cypress.io

*1:たとえば .find でチェーンするときなど

2021-09-24

OS起動時に Elasticsearch などの「重い」サービスがタイムアウトで自動起動に失敗するときの対処法

ソフトウェアソフトウェア開発 OS -> Linux

前提条件

Ubuntu です。

エラー例

以下のようにタイムアウトでエラーになります.

$ sudo service elasticsearch status
● elasticsearch.service - Elasticsearch
     Loaded: loaded (/lib/systemd/system/elasticsearch.service; enabled; vendor preset: enabled)
     Active: failed (Result: timeout) since Sun 2021-08-29 15:31:13 JST; 19s ago
       Docs: https://www.elastic.co
    Process: 1990 ExecStart=/usr/share/elasticsearch/bin/systemd-entrypoint -p ${PID_DIR}/elastic>
   Main PID: 1990 (code=exited, status=143)

結論

サービス開始スクリプト中の TimeoutStartSec の値を十分に大きくする。

例

Elasticsearch の例です。/lib/systemd/system/elasticsearch.service を編集します。

# Allow a slow startup before the systemd notifier module kicks in to extend the timeout
# TimeoutStartSec=75
TimeoutStartSec=300

編集したあとはリロードします。

$ sudo systemctl daemon-reload

これで再起動後に十分な時間をもってサービスが起動するはずです。

2021-09-21

Elasticsearch のデータディレクトリを変更する際は /etc/elasticsearch/elasticsearch.yml を変更するだけではだめ

ソフトウェア

結論

/etc/elasticsearch/jvm.options にもディレクトリを指定するところがありますので、そちらも変更します。

補足

/etc/elasticsearch/elasticsearch.yml 内に自分で追記したディレクトリがある場合には、それにも注意する必要があります*1。

*1:たとえば configsync.config_path: