


ジョブ毎に[https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip](https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip)からダウンロードしてるのでこれをCircleCIのキャッシュを入れてみましたが、もともと３秒の処理時間は全く改善しなかった話

## Before

```yml
  - run:
    name: Install aws-cli
    command: |
      curl -s "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
      unzip -q awscliv2.zip
      sudo ./aws/install
```

## After

```yml
  - when:
    condition: true
    steps:
      - restore_cache:
          key: awscli-exe-linux-x86_64_zip_20220831
      - run:
          name: Install aws-cli
          command: |
            [ ! -f /tmp/awscliv2.zip ] && curl -s "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
            unzip -q awscliv2.zip
            sudo ./aws/install
          working_directory: /tmp
      - save_cache:
          key: awscli-exe-linux-x86_64_zip_20220831
          paths:
            - /tmp/awscliv2.zip
```

インスタンスサイズsmallでも３秒（たまに2秒）だったものが1秒+2秒+0秒と全く変わらない結果に。むしろたまに2秒だけなので負けてる疑惑さえある。

ネットワーク消費減って課金が微減したかもしれないけど、コードの複雑性を増してまで得るメリットではないので戻そう、、

そもそも全ジョブに入ってるとはいえ、３秒のものを更に減らそうとすべきじゃなかった


ジョブ毎に<a href="https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip">https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip</a>からダウンロードしてるのでこれをCircleCIのキャッシュを入れてみましたが、もともと３秒の処理時間は全く改善しなかった話
<h2 id="before">Before</h2>
<pre><code class="hljs language-yml"> - run:
 name: Install aws-cli
 command: |
 curl -s &quot;https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip&quot; -o &quot;awscliv2.zip&quot;
 unzip -q awscliv2.zip
 sudo ./aws/install
</code></pre>
<h2 id="after">After</h2>
<pre><code class="hljs language-yml"> - when:
 condition: true
 steps:
 - restore_cache:
 key: awscli-exe-linux-x86_64_zip_20220831
 - run:
 name: Install aws-cli
 command: |
 [ ! -f /tmp/awscliv2.zip ] &amp;&amp; curl -s &quot;https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip&quot; -o &quot;awscliv2.zip&quot;
 unzip -q awscliv2.zip
 sudo ./aws/install
 working_directory: /tmp
 - save_cache:
 key: awscli-exe-linux-x86_64_zip_20220831
 paths:
 - /tmp/awscliv2.zip
</code></pre>
インスタンスサイズsmallでも３秒（たまに2秒）だったものが1秒+2秒+0秒と全く変わらない結果に。むしろたまに2秒だけなので負けてる疑惑さえある。
ネットワーク消費減って課金が微減したかもしれないけど、コードの複雑性を増してまで得るメリットではないので戻そう、、
そもそも全ジョブに入ってるとはいえ、３秒のものを更に減らそうとすべきじゃなかった

AWSCLIのインストールにキャッシュを使ってみたけど大して減らなかった話



モノレポ運用をしてるPJにて、導入寸前まで思案したcircleci/path-filteringというorbsですが、導入を諦めた懸念点をメモします

## ズバリ冪等性が下がる
指定したフォルダ配下の変更点を検知して条件分岐を可能にするというのはモノレポ運用時に実行する必要があるワークフローだけを実行できとてもエコで魅力的でした。問題点は差分というのが「何と比較して」であると思います。

ドキュメントによると`base-revision`というパラメータに比較対象のブランチを指定するようで、デフォは`main`、つまりブランチを指定するということ。これはCircleCIのジョブをrerunした時に、比較対象ブランチの状態が不定であるため、同一HEADのrerunにも関わらず、どのワークフローが走るかがタイミング毎に異なるリスクがあるということです。

本番デプロイしてやらかした際に、手っ取り早く一つ前のCIをrerunすればロールバックできる仕組みであってほしいですが、想定のワークフローが起動しない、別のワークフローが起動するリスクを考慮したくないと思いました。

ブランチを指定する仕様にケチをつけるつもりはなく、極めて妥当だと思います。しかし無茶を承知で欲を言えば、rerunした時には初回runと常に同じon/offが設定されてここの冪等性は確保されてほしいと思いました。

## References

- https://circleci.com/developer/orbs/orb/circleci/path-filtering
- https://blog.adachin.me/archives/48488
- https://zenn.dev/korosuke613/scraps/74e6ccaf6f8b67

モノレポ運用をしてるPJにて、導入寸前まで思案したcircleci/path-filteringというorbsですが、導入を諦めた懸念点をメモします
<h2 id="ズバリ冪等性が下がる">ズバリ冪等性が下がる</h2>
指定したフォルダ配下の変更点を検知して条件分岐を可能にするというのはモノレポ運用時に実行する必要があるワークフローだけを実行できとてもエコで魅力的でした。問題点は差分というのが「何と比較して」であると思います。
ドキュメントによると<code>base-revision</code>というパラメータに比較対象のブランチを指定するようで、デフォは<code>main</code>、つまりブランチを指定するということ。これはCircleCIのジョブをrerunした時に、比較対象ブランチの状態が不定であるため、同一HEADのrerunにも関わらず、どのワークフローが走るかがタイミング毎に異なるリスクがあるということです。
本番デプロイしてやらかした際に、手っ取り早く一つ前のCIをrerunすればロールバックできる仕組みであってほしいですが、想定のワークフローが起動しない、別のワークフローが起動するリスクを考慮したくないと思いました。
ブランチを指定する仕様にケチをつけるつもりはなく、極めて妥当だと思います。しかし無茶を承知で欲を言えば、rerunした時には初回runと常に同じon/offが設定されてここの冪等性は確保されてほしいと思いました。
<h2 id="references">References</h2>
<ul>
<li><a href="https://circleci.com/developer/orbs/orb/circleci/path-filtering">https://circleci.com/developer/orbs/orb/circleci/path-filtering</a></li>
<li><a href="https://blog.adachin.me/archives/48488">https://blog.adachin.me/archives/48488</a></li>
<li><a href="https://zenn.dev/korosuke613/scraps/74e6ccaf6f8b67">https://zenn.dev/korosuke613/scraps/74e6ccaf6f8b67</a></li>
</ul>

circleci/path-filteringの欠点

Nextとしてサーバーを建てるのではなく、RailsのViewからscriptタグでJS配信するだけなら、本番イメージ内にインストールする必要ないのでは？と思ったらできた話

## 1. Dockerfileからnodeを取り除く

よくある下記のようなDockerfileではこれだけで数百MBイメージサイズが増える。これを外す

```Dockerfile
RUN apt-get install -y nodejs npm && \
 npm install -g yarn

COPY package.json yarn.lock ./
RUN yarn install
```

## 2. assets:precomplieはCircleCIでやる

こんな感じでorbsをフル活用するとスムーズにDockerfile外でビルドできた。rubyもnodeもキャッシュをよしなにしてくれるのでとても高速

```yml
version: "2.1"

orbs:
 ruby: circleci/ruby@1.4.0
 node: circleci/node@5.0.0

jobs:
 check:
 docker:
 - image: cimg/ruby:3.1-node
 steps:
 - checkout
 - ruby/install-deps
 - node/install-packages:
 check-cache: detect
 pkg-manager: yarn
 - run: bin/rails assets:precompile
```

## 3. manifestをイメージに追加する

S3からの配信を予定しているが、マニフェストファイルだけはイメージに取り込まないと`javascript_pack_tag`などが正常に動作しなかった。

webpackerのものは`public/packs/manifest.json`と固定値だが、アセットパイプライン本体のものは`public/assets/.sprockets-manifest-<< hash >>.json`といった動的なパスになる。

Dockerfileでは`COPY . .`して全追加する際にマニフェストだけは追加しつつJS、CSSは除外するように`.dockerignore`を調整した。

```bash
/public/assets
!public/assets/.sprockets-manifest-*.json
/public/packs
!public/packs/manifest*
```

なおCI上でこのままAWS CLIを使ってS3に丸ごとアップロードすれば、Rails内に`asset_sync`, `fog-aws`を追加する必要もない。

最後にCDN配信なので、asset_syncを使わない場合は`config.asset_host = ENV['CDN_HOST']`といった具合にホストを指定して無事に配信ができた。

Nextとしてサーバーを建てるのではなく、RailsのViewからscriptタグでJS配信するだけなら、本番イメージ内にインストールする必要ないのでは？と思ったらできた話
<h2 id="1-dockerfileからnodeを取り除く">1. Dockerfileからnodeを取り除く</h2>
よくある下記のようなDockerfileではこれだけで数百MBイメージサイズが増える。これを外す
<pre><code class="hljs language-Dockerfile">RUN apt-get install -y nodejs npm &amp;&amp; \
 npm install -g yarn

COPY package.json yarn.lock ./
RUN yarn install
</code></pre>
<h2 id="2-assetsprecomplieはcircleciでやる">2. assets:precomplieはCircleCIでやる</h2>
こんな感じでorbsをフル活用するとスムーズにDockerfile外でビルドできた。rubyもnodeもキャッシュをよしなにしてくれるのでとても高速
<pre><code class="hljs language-yml">version: &quot;2.1&quot;

orbs:
 ruby: circleci/ruby@1.4.0
 node: circleci/node@5.0.0

jobs:
 check:
 docker:
 - image: cimg/ruby:3.1-node
 steps:
 - checkout
 - ruby/install-deps
 - node/install-packages:
 check-cache: detect
 pkg-manager: yarn
 - run: bin/rails assets:precompile
</code></pre>
<h2 id="3-manifestをイメージに追加する">3. manifestをイメージに追加する</h2>
S3からの配信を予定しているが、マニフェストファイルだけはイメージに取り込まないと<code>javascript_pack_tag</code>などが正常に動作しなかった。
webpackerのものは<code>public/packs/manifest.json</code>と固定値だが、アセットパイプライン本体のものは<code>public/assets/.sprockets-manifest-&lt;&lt; hash &gt;&gt;.json</code>といった動的なパスになる。
Dockerfileでは<code>COPY . .</code>して全追加する際にマニフェストだけは追加しつつJS、CSSは除外するように<code>.dockerignore</code>を調整した。
<pre><code class="hljs language-bash">/public/assets
!public/assets/.sprockets-manifest-*.json
/public/packs
!public/packs/manifest*
</code></pre>
なおCI上でこのままAWS CLIを使ってS3に丸ごとアップロードすれば、Rails内に<code>asset_sync</code>, <code>fog-aws</code>を追加する必要もない。
最後にCDN配信なので、asset_syncを使わない場合は<code>config.asset_host = ENV[&#39;CDN_HOST&#39;]</code>といった具合にホストを指定して無事に配信ができた。

UMIHICO BLOG.

#CircleCI

AWSCLIのインストールにキャッシュを使ってみたけど大して減らなかった話

circleci/path-filteringの欠点

React on Railsで本番イメージをNodeレスにした