これはノウハウとかじゃなくてただの日記。
この前久々にLenovoのPCを触れたので、Docker for Windowsの設定をして、WSLでdocker-compose upできて喜んでいたが、Railsアプリを起動するところまで時間が取れなかった。昨日ようやく少し時間が取れたのでやってみたところ、動いた。WSLでbin/rails sしてから普通にhttp://localhost:3000にアクセスして画面を表示することもできた。
できたが、めちゃくちゃ遅かった。画面遷移するのに10秒以上かかっていたんじゃないかと思う。初回のアクセスはJSとCSSのトランスパイルが実行されるからもっと遅かった。1分半くらいかかっていたように思う。さすがに開発に使うには厳しい。
WSLの起動自体はめっちゃ速いし、普通に使う分には問題ないのだけれど、どうしたもんかなぁ…という気持ち。vagrantにUbuntuを入れてそこに開発環境をセットアップしたほうがいいのかな？いい方法をご存知の方がいれば教えてください。
我が家ではルータにTimeCupsuleを使っていたのだが、これがフレッツのIPv6に対応していないせいで、NTT西日本のClub NTT-WESTのポイント交換がうまくいかないというここ数年の悩みがあった。
話はさかのぼること数年前。
Club NTT WESTはフレッツを使っていたらポイントが貯まっていって、結構豪華なものと交換できたりする。長年使っていると、ボーナスポイントがもらえたりもする。私はいつも、このポイントをiTunes Cardに交換して、App Storeでアプリを買う時の足しにしていた。ところがある日、ポイント交換しようとしたら、ご契約の回線からのアクセスかをIPv6で認証する、ということをやり始めたのである（ただし、ポイントカード類のみ）。これで急にiTunes Cardがもらえなくなってしまい、途方に暮れていた。
そして時は今月。
気づけば、「2019年4月にポイントが失効しますよ！」という通知が来ていた。いや使いたいのに使わせないのそっちやろ！と思いつつも、失効するくらいならなんか違うものに交換するかぁ〜と思い、物色していたら、さすがNTTのポイント交換サービスだけあって、ネットワーク機器まであった。
ルーターに交換できるのならば、TimeCupsuleに代わってこれにしてしまえば、またiTunes Cardとかに交換できる！と思い、今回はI-O DATAのWN-AX1167GR2と交換した。
そして待つこと10日くらいで届いた。
ルーター届いた pic.twitter.com/vZrvpdsc5i
— パトラッシュ@育休終了 (@patorash) 2019年3月20日
早速、交換にとりかかる。その前に、速度を計測。
作業前の速度。あれ〜？こんなに出てたかな？ | 使用中のインターネットの速度は: 150Mbps. お使いのインターネットの速度はどのくらいですか? https://t.co/MiQdisxYeu
— パトラッシュ@育休終了 (@patorash) 2019年3月20日
設定はまぁまぁ簡単だった。のだけれど、うちのプロバイダはASAHIネットなので、事前にIPv6の利用申請が必要。まぁこれはTimeCuspuleでIPv6を試す時にすでに行なっていたので問題なかった。 ただ、後でわかったのだけれど、ルーターのIPv6動作確認済みプロバイダ一覧にASAHIネットがなかった…。
IPv6設定を行うために、詳細ガイドを見ながら作業をした。
しかし、
① ［ステータス］メニューの［インターネット設定］で［接続方法］を確認する ② ［v6プラス,IPv6オプションなど］または［transix］になっていれば接続完了です
と書いてあるにも関わらず、我が家はなぜかPPPoEになってしまう。手動でv6プラスやtransixにしてみたが、インターネット接続が切れるだけ…。
何度かやっていると、気づいたらPPPoEだけれど、IPv6パススルーが有効になっていた。この状態でIPv6になっているか確認する用のページにアクセスしたら、うまくいっていた！
本当にこれでいいのか、Club NTT WESTでポイント交換できるか確認したところ、成功！ようやくIPv6環境が手に入った！
そして、再び速度チェック。
速くなったけれど、もっとなるかなと思ったが、そうでもなかった。 | 使用中のインターネットの速度は: 250Mbps. お使いのインターネットの速度はどのくらいですか? https://t.co/vOuGJEAvls
— パトラッシュ@育休終了 (@patorash) 2019年3月20日
150Mbpsから250Mbpsなので、まずまず速くなったと思う。さて、あとはTimeCupsuleをこれからどうしていくか、というところ。TimeMachineを使っているので、これからも活かしていきたい。
Rubocopを一応入れているのに、滅多に動かしてなくてあんまり意味を成していなかった。issueにずっとあったCIにRubocopを取り入れるというやつに着手しようと思ってようやく取り組み始めた。
CircleCIのワークフローにRubocopのチェックを入れて、自動的にコメントをしてもらいたいなぁと思って調べていたら、reviewdogを知った。
自分がやりたかったことはまさにこれだったので、これを参考にすることに。
reviewdogのインストールは本家を参考にした。
バイナリで配布もされているが、goenvでgoを入れているので、go getを使って入れた。
$ go get -u github.com/haya14busa/reviewdog/cmd/reviewdog
reviewdogが実行できない場合はパスが通ってないってことなので、パスを通しましょう。
Rubocopのルールをよく把握してなかったので、チームで以前に作ったルールを実行してみたら、かなりの量で怒られたので、たぶんプロジェクトにルールがまだ合ってないなと思ったので、一から作り直そうと思った。
とはいえ、ルールの数も途方もないだろうし、有名な指針があればいいかなと思って調べ始めたら、onkさんのRubocopの記事を見つけた。
スモールスタートの仕方が書いてあったので、まずはそれを検証することに。
bundle exec rubocop --auto-gen-configを実行して.rubocop.ymlと.rubocop_todo.ymlを生成するbundle exec rubocop --parallelを実行して指摘がないことを確認するという方針を立てた。
とりあえず、rubocop.old.ymlで怒られていたルールを実行してみると、たくさん指摘された。
それをreviewdogに食わせてみることに。
$ bundle exec rubocop --parallel --only Layout/SpaceAroundEqualsInParameterDefault | reviewdog -f=rubocop -diff="git diff"
何も表示されない！
しかしこれは当然の話で、reviewdogは変更のあった行でrubocopの指摘がある場合のみ通知してくる。まだコード自体は一切変えていなかったからだ。そこで、敢えてコードをルールに違反するコードに変えたところ、ちゃんと指摘された。
上のほうで参考にしたサイトの通りにすれば動くので、特に書くことはない…んだけど、一応書く。ちなみにcircle.ymlのフォーマットはCircleCI 2.1なのであしからず。
executorsのrubyのdocker imageの環境変数に、reviewdogのバージョンを指定する。
executors: default: docker: - image: patorash/circle_ci_ruby:2.5.3-node-browsers-pg11 environment: RAILS_ENV: test REVIEWDOG_VERSION: 0.9.11 # ここ
次に、reviewdogを実行するcommandsを定義する。
commands: # 他のコマンドは略 run_reviewdog: steps: - run: name: Install reviewdog command: | curl -fSL https://github.com/haya14busa/reviewdog/releases/download/$REVIEWDOG_VERSION/reviewdog_linux_amd64 -o reviewdog chmod +x ./reviewdog - run: bundle exec rubocop | ./reviewdog -f=rubocop -reporter=github-pr-review
次に、workflowを定義。テストが実行される前にrobocopで検査して、問題があればそこで止めるようにする。まだジョブの定義はしていないが、とりあえずワークフローを先に書く。
workflows: build: jobs: - prepare_test - reviewdog: requires: - prepare_test - retry_failed_test: requires: - reviewdog - test: requires: - retry_failed_test
しかしこれだとreviewdogが通らないとテストすら実行されないので、緊急時とかにうざいかもしれない…。そのときは、retry_failed_testのrequiresをprepare_testに変えてしまうほうがいいかも…とこの記事を書きながら思った。
さて、reviewdogジョブを定義する。もうcommandsを定義しているので、それを呼び出すだけである。一応prepare_testも載せておくが、やってることはcommand名から想像してほしい。
jobs: prepare_test: parallelism: 1 executor: default steps: - checkout - restore_node_module_cache - restore_bootsnap_cache - ruby-orbs/bundle-install - yarn_install - save_node_module_cache - save_code_cache reviewdog: parallelism: 1 executor: default steps: - restore_code_cache - run: bundle --path vendor/bundle - run_reviewdog # 他のジョブは略
これでcircle.ymlは完成。
あとはgithubでreviewdogでコメントさせるユーザーのトークンを環境変数REVIEWDOG_GITHUB_API_TOKENに定義しなくてはならない。
この時、もし自分のアカウントで取得すると、reviewdogのコメントをしてくるのが自分のアカウントになる。別に問題ない人はそれでいいが、個人アカウントで機械的にであっても個人のアイコンがある状態でコメントされると、なんか殺伐としそう…。なので、bot用の別アカウントを作るなりして、そいつにコメントしてもらうほうがいいと思う。onkさんの記事でも、カーチャンに指摘してもらうみたいに書いてた。
話を元に戻すが、repoにチェックを入れてアクセストークンを発行する。
発行したアクセストークンは、CircleCIのプロジェクト毎の環境変数に保存しておく。
これで完了。
あとは、先ほど設定したcircle.ymlを含むbranchをpushして、PRにしてreviewdogがコメントするのを確認すればよし。ちゃんとCIのワークフローがそこで止まることも確認する。
そして、指摘された点を修正し直して、ワークフローが全部通ることを確認する。
オーケー、完成だ。
CircleCIのworkflowにreviewdogを入れられたのは一歩前進。とはいえ、rubocopはスモールスタートの設定をしただけなので、ルールを決めていく必要がある。onkさんが公開しているonkcopが参考になりそうなので、それを読みながら一部を自分のルールで上書きしていこうと思う。
gem rmagick 3.0.0を入れようとしたら、bundle installのときにImageMagickのバージョンが古いという理由で落ちました。というわけで、ImageMagickのアップデートやります！
ここに書かれてることをやれば概ね大丈夫かと思いますが、最初CentOS6系のリポジトリを入れる理由がよくわからなかったので、そこを無視して色々試していたのですが、依存性解決が全然うまくいかず…。
さらにググり続けることに。今度は依存性解決できなかったsoファイル名とかで以下の記事がヒット。
あ〜、soファイルがあるのがCentOS6系のリポジトリなのか…と理解し、ようやく追加。
$ sudo touch /etc/yum.repos.d/CentOS-Base.repo
$ sudo vi /etc/yum.repos.d/CentOS-Base.repo
[base] name=CentOS-6 - Base mirrorlist=http://mirrorlist.centos.org/?release=6&arch=x86_64&repo=os gpgcheck=1 enabled=0 gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-6
古いImageMagickを削除し、新しいImageMagickをインストールしました。
$ sudo yum remove ImageMagick ImageMagick-libs ImageMagick-devel
$ sudo yum install ImageMagick6 ImageMagick6-libs ImageMagick6-devel --enablerepo=remi,epel,base
その後、bundle installでrmagick 3.0.0のインストールが成功しました。
まず、PostgreSQLのyumリポジトリを追加します。 参照先は以下。
Amazon Linux 1はRedHat Enterprise Linux6互換(？)のため、そのURLをコピーして追加します。そのあと、/etc/yum.repos.d/pgdg-11-redhat.repoに記載されているURLをsedで置換します。
$ sudo yum install https://download.postgresql.org/pub/repos/yum/11/redhat/rhel-6-x86_64/pgdg-redhat11-11-2.noarch.rpm $ sudo sed -i "s/rhel-\$releasever-\$basearch/rhel-6.10-x86_64/g" "/etc/yum.repos.d/pgdg-11-redhat.repo"
あとは、インストールするだけ。クライアントだけ欲しかったのでpostgresql11, postgresql11-develのみを指定しています。
$ sudo yum install -y postgresql11 postgresql11-devel
psqlのバージョンを確認して終わり。
$ psql --version psql (PostgreSQL) 11.2
gem pgのインストールでこけた…。pg_configが見つからないと言われた。
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.
current directory: /home/heroku/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/pg-1.1.4/ext
/home/heroku/.rbenv/versions/2.5.3/bin/ruby -r ./siteconf20190307-22703-1t1ti1k.rb extconf.rb
checking for pg_config... no
No pg_config... trying anyway. If building fails, please try again with
--with-pg-config=/path/to/pg_config
checking for libpq-fe.h... no
Can't find the 'libpq-fe.h header
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details. You may
# .bash_profile
need configuration options.
/usr/pgsql-11/binにPATHを通せばいいことがわかった。
.bash_profileを編集する。
PATH=$PATH:/usr/pgsql-11/bin export PATH
source ~/.bash_profileしてから、bundle installしたら成功した。
PostgreSQL 11にアップデートしようとしていたときに起きました。
docker imageを11に変更して、CircleCIでテストを流そうとしたところ、bin/rake db:structure:loadで失敗しました。
psql:/home/circleci/workspace/db/structure.sql:15: ERROR: schema "public" already exists
該当行はCREATE SCHEMA public;をやろうとしていたのですが、publicは最初から存在するので、そりゃエラーになるわな…と。
今まで出てなかったのに、なんでだろう？と思いつつ、Railsのコードを追ってみました。
search_pathに値があれば、--schema=値を設定するようだったので、database.ymlを確認したら、schema_search_path: publicと書いていました…。もういつ書いたのかほとんど覚えてないけれど。これをコメントアウトしてからrake db:migrateを行い、db/sctructure.sqlを再生成したところ、CREATE SCHEMA public;の表記がなくなりました。
schema_search_pathにはpublic以外のスキーマを作った時に、それらを指定したほうがよさそうです。
3/5にあったCircleCIのミートアップにリモートで参加させてもらいました。
イベントのConnpassはこちら。
ちょうどCircleCIをPerformancePlanに移行したりしていたので、CircleCI Japanの方からZoomで参加しませんか？とtwitterのDMで連絡を頂きました。
せっかくの機会なので、参加させていただくことに。
この時に、社外の方も参加募集したのですが、悲しいことに集まらなかったので、社内のメンバー4人で参加しました。
弊社でもJenkinsでの並列テストを経た後にCircleCIの導入をしているので（1.0の頃から）、「あ〜、わかるわ〜」という感じでした。
CI環境はCircleCIになるまではほぼ関与してないので、記憶で書く（間違ってるかも）
高速化には色々と取り組みました。
今回の参加者は私以外は入社2年以内の若者が3名だったのだけれど、上記のような歴史を知らないので、
若者たち「Jenkinsってなに？？？🤔」
ってなっていたので、発表は聞きつつもCI導入の歴史を説明したりしました。まぁいい機会だったのかもしれないですねぇ。
現地はピザや飲み物があったりしたみたいで羨ましかったですが、実はこちらもピザを食べてました！
発表後のネットワーキングの時間とかはリモートだと参加できないので、やっはり現地がいいなぁと。まぁ岡山だとなかなか厳しいんですが。機会があったら現地参加したいと思います！
