プルリクエストを制御する danger というものがあるらしい

danger とは

CI の内容に応じて、さまざまな制御をしてくれるパッケージ。

github.com

その中で PR の制御とかも入っているので、ちょっと触ってみた。

やったこと

サンプルに載っていたものを拝借して、こんなコードを実装した。

name: test danger JS
on: [pull_request]

jobs:
  build:
    name: Danger JS
    runs-on: ubuntu-latest
    permissions: write-all
    steps:
      - uses: actions/checkout@v3
      - name: Use Node.js 10.x
        uses: actions/setup-node@v4
        with:
          node-version: 20.9.0
      - name: install yarn
        run: npm install -g pnpm
      - name: pnpm install
        run: |
          pnpm install  --frozen-lockfile
      - name: Danger
        run: |
          yarn danger ci
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          DANGER_DISABLE_TRANSPILATION: true

push し、PR を作成してみたら、こんな感じのアウトプットになった。

コメントでの出力

CI の出力

まとめ

自分たちが定義した通りに、コメントや CI の結果を出してくれるものなので、github の branch protection rule とかと一緒に運用すると効果が出そう。

フロントエンドにおけるディレクトリ構成について

# 個人的な見解

個人的には、package by feature で関心ごとで整理するのがよさそうだと感じている。特に複雑なドメインを扱うようなサービスにおいては、こうするのが最適だと思っている。技術的レイヤーのディレクトリは関心ごとで整理しているなかで吸収する必要のあるものが出てきた時に作成するのが良いのではないかと感じている。

# 参考

- [アンチパターンを理解して package by feature へ](https://zenn.dev/misuken/articles/bdd33790ed4cd0)

- [フロントエンドのディレクトリ設計思想](https://zenn.dev/mybest_dev/articles/c0570e67978673)

 

grep って検索文字列に合致しないとエラーになるらしいぜ

どういうことが起きたか？

下記コマンドをローカルのコマンドラインで実行しているときは気づかなかったが、いざ GitHub Actions 上で実行すると、Error: Process completed with exit code 1. が出力されてしまい、エラーの扱いになってしまう。

echo xxx | grep -c yyyy

参考にした記事を見ると、下記コマンドで対処できるっぽい。

echo xxx | grep -c yyyy || [[ $? == 1 ]]

実際、これで対処することができたので、この現象にハマったらこのコマンドを追加しよう。

参考