ローカル Webサーバ の比較と選択

ソフトウェア開発 Web

手元の HTML / CSS / JavaScript をサクッと確認するためには ローカルWebサーバ を建てる必要があります*1。思いついたローカルWebサーバの簡易比較をしてみます。

比較項目は以下のとおりです。それぞれの項目の内容は、最低限のオプションで起動した場合の内容です。

  • 起動方法
  • ディレクトリのファイル一覧を表示できるか
  • 文字コードを指定しなくても大丈夫か*2
  • ポート番号
  • 備考

*1:ファイルを直接開くことは制約が多すぎるので、現在では無いと思います

*2:生の UTF-8 の .md ファイルを開いたときに日本語が正しく表示されるか

続きを読む

CircleCI で cron を設定する方法

ソフトウェア開発

公式ドキュメント

CircleCI は公式ドキュメントが充実していますので、一読しましょう*1。

circleci.com

YAML の例

cron を実行するための最低限に近い .circleci/config.yml の例は次のとおりです。

*1:ぶっちゃけ公式ドキュメントを読み込めばほぼ分かってしまいます

続きを読む

GitHub Actions で cron を設定する方法

ソフトウェア開発

公式ドキュメント

日本語のドキュメントは、例え用意してあったとしても、情報が古いことがあるので気をつけましょう*1。

https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

YAML の書き方

cron を設定するための最小限の YAML を書くと次のようになります。

name: FOOBAR
on:
  schedule:
    - cron: '34 12 * * *'
jobs:
  my_cron_job:
    name: hogehoge
    runs-on: ubuntu-latest
    steps:
    - name: Hello My Cron Job
      run: |
        echo 'Hello, My Cron Job!'

上記を push すると「日本時間で毎日 21:34 に my_cron_job の内容が実行」されます。

注意点

細かい注意点がいくつかあります。

  • 時刻指定の際のタイムゾーンは UTC(GMT) です
    • したがって「日本の時刻から 9時間マイナスした時刻」を指定する必要があります
    • また、日付を指定する場合には、日付のまたぎによるミスに注意する必要があります
  • YAML において * は特別な文字なので、cron: で指定する値はクォートする必要があります
  • 最小の実行可能時刻の間隔は 5分 なので、実際に実行される時刻は分単位で見ると結構いい加減な印象です
    • daily / nightly ビルドや、深夜に時間をかけて回すビルド などに使う分には全く問題ないと思います
  • 「実行対象となるブランチはデフォルトブランチ」です
    • これが結構ハマりやすいです

gyazo.com

補足

冒頭の YAML の書き方ですと、cron でしか job が発動しません。push でも発動させたい場合は以下の 2つ の方法があります*2。

1つ目の方法: 冒頭の YAML の on: の値に push: を追加する

発動の契機として push: を追加します。キーのみの追加で良いです*3。追加したあとの YAML は次のようになります。

name: FOOBAR
on:
  push:
  schedule:
    - cron: '34 12 * * *'
jobs:
  my_cron_job:
    name: hogehoge
    runs-on: ubuntu-latest
    steps:
    - name: Hello My Cron Job
      run: |
        echo 'Hello, My Cron Job!'

2つ目の方法: 発動契機の種類ごとに YAML ファイルを分割する

GitHub Actions では .github/workflows 直下にある YAML ファイル全てを GitHub Actions の設定ファイルとみなします。

したがって、「on: に push: のみを設定した YAML ファイル」を一つ書き、さらに「on: に schedule: のみを設定した YAML ファイル」を一つ書けば、on: と push: の両方を契機にして job を発動させられます。

この方法だと push: と schedule: で異なる内容の job を実行させることができます*4。

ログの出力について

GitHub Actions の実行ログ一覧では、何を発動契機としたか、が一覧に表示されるので、それにより schedule: を契機として発動したことを確認することができます。

gyazo.com

*1:この記事の内容も古くなっていることがあり得ます

*2:他にもあるでしょう

*3:値は空っぽで良い

*4:ただし、両方で全く同じ内容の job を実行させたい場合は典型的な 非DRY なファイル構成になります

GitHub Actions のキャッシュ容量の上限は 400MB（なので wkhtmltopdf-binary を入れていると厳しい）

ソフトウェア開発 プログラミング -> Ruby on Rails

注意事項

  • 2020/01/06 時点での話です
  • 単一実行時のキャッシュの話です

状況

GitHub Actions で bundle install した gem のキャッシュが保存できるようになったので喜んで使っていたのですが、とある日にログを見たところ、以下のような表示が出ていました。キャッシュ容量の上限の 400MB を超えている、との警告です。

 [warning]Cache size of ~526 MB (551997667 B) is over the 400MB limit, not saving cache.

gyazo.com

何がそんなに容量を喰っているのか

gem の総容量が 400MB を超えるなんて普通ではどう考えてもありえません。何がそんなに容量を喰っているのかを以下のように調べました。

続きを読む
Powered by はてなブログ