無職です。はたらいてます。 旧ブログ: 1 Entry per Day

真似しちゃいけないdeployステップの使い方

これはCircleCI Advent Calendar 2019の8日目の記事です。

qiita.com


こんにちは、CircleCI大プッシュしてたらCircleCIの回し者だと思われた@mstsskです。

今回はdeployステップの変な使い方を思いついたので紹介します。

ただし、真似しちゃいけません。

deployステップについて

CircleCIでは、CIジョブで実行するコマンドのステップをrunというキーワードで記述します。 そして実はdeployというキーワードでもコマンドを記述できるようになっています。

deployステップの書き方はrunと同じですが、文字通りデプロイのためのステップであり、動作が異なります。

parallelism を使ったジョブの場合、deploy ステップは他のすべてのノードが成功した場合にのみ、ノード番号 0 として実行されます。 ノード番号 0 以外はステップを実行しません。

引用元: https://circleci.com/docs/ja/2.0/configuration-reference/#deploy

deployステップを使ったconfig.ymlは次のような感じになります。

# .circleci/config.yml
version: 2.1
jobs:
  build:
    docker:
      - image: circleci/ruby
    parallelism: 4 # 4並列で実行
    steps:
      - checkout
      - run: bundle install
      - run: # circleciコマンドを使ってテストを4分割して実行
          name: Parallel Testing
          command: bundle exec rspec $(circleci tests glob spec/**/*.rb | circleci tests split)
      - deploy: # テストが通ったらデプロイ。このステップは4つのノードのうち0番目でだけ実行される
          name: Deploying to dev env
          command: bundle exec cap dev deploy

つまり、deployステップを使うとCircleCIのジョブの中で並列処理の待ち合わせができるんです!

待ち合わせ処理を書いてみる

並列実行している処理の待ち合わせが書けるなら、あとはデータの受け渡しができれば、もう並列処理のプログラム書けるようなもんだよね? 例えば、大きな処理の分割実行とその結果の統合が1つのジョブの中で済ませられるのでは?と考えてやってみました。

deployステップで並列実行の待ち合わせをして、各ノードの結果をCircleCIのキャッシュ経由で受け渡しするサンプルは次のとおりです。

# .circleci/config.yml
version: 2.1
jobs:
  build:
    docker:
      - image: circleci/node:12
    parallelism: 4
    steps:
      - checkout

      # 成果物を result-{ノード番号}.txt に保存する、ビルドとかテスト実行など並列実行したい遅い処理
      - run:
          name: Building Some Results
          command: |
            mkdir results/ &&
            ./dummy_slow.sh > results/result-$CIRCLE_NODE_INDEX.txt

      # 成果物をキャッシュに保存
      - save_cache:
          key: results-{{ .BuildNum }}-{{ .Environment.CIRCLE_NODE_INDEX }}
          paths:
            - results/

      # 各ノードのビルド実行・キャッシュ保存を待つ
      - deploy:
          name: Waiting Results
          command: ":"

      # 各ノードの成果物をキャッシュから取り出す
      - restore_cache: { keys: ["results-{{ .BuildNum }}-1"] }
      - restore_cache: { keys: ["results-{{ .BuildNum }}-2"] }
      - restore_cache: { keys: ["results-{{ .BuildNum }}-3"] }

      # 0番目のノードで他ノードの成果物を組み合わせる
      - deploy:
          name: Merging Results
          command: |
            ls results/
            echo
            cat results/result-*.txt

restore_cache のところがどうしても冗長な書き方になりますが、これで1つのジョブの中で並列実行した結果を統合できます。

もうちょっとconfig.ymlを整理したサンプルは↓。

https://circleci.com/gh/mstssk/circleci-deploy-step-play github.com

何に使うの?

もともとは、並列テストのカバレッジデータをサクッと統合したいと思ってなんとかジョブの中でミニマムに解決できないかと考えて思いついたものです。

実際にジョブの中でデータ集めができることを確認したあたりで正気に帰りました。 本来の使い方とは違うやり方だけど試行錯誤してなんとかなったぜやったぁ状態になる瞬間ってたまにありますよね。

よっぽど1つのジョブの中で完結させたい理由がもしあったなら使えるテクニックかもしれませんが、本当に必要かどうか3回考えてから諦めましょう。 普通に別ジョブにしてpersist_to_workspaceでデータ受け渡してやりましょう。

カバレッジデータの統合をしたい場合は、各カバレッジツールがCircleCIの場合の使い方サンプルを公開してたりしますし、Coverallsは結果をよしなにマージしてくれる機能があるらしいです1

width属性の詳細度は要素セレクタよりも低い

img要素などいくつかのHTML要素では widthheight を属性で書いてもよい。

<img width="100px" src="foobar">

しかし、このwidth属性に対してCSSでもwidth指定をしていたら、どちらが優先されるのか。 <img width="100px"><img style="width:100px;"> は挙動が違うというのはわかって入るが、具体的にどうなんだろうと思って調べてみた。

ざっくり調べた結論としては、属性でwidthを指定するのは何よりも優先度(詳細度)が低いというつもりでいればいいだろう、という感じ。

width属性はCSSじゃないので詳細度という言い方が適切かはわからない。

あと、スタイルと一緒くたにしてしまったが、本来はスタイルの指定に使うものではない。 HTML5.2のspecを一部読んだ感じでは、width属性とheight属性両方とも同時に指定するのが本来の仕様であり、ユーザーエージェント(ブラウザ)はその値を描画のヒントとすることを期待するものとのこと。

実際のブラウザの挙動を確認するのはstackblitzで適当にサンプルコード書いた。 Safari, Chrome, Firefoxあたりで確認して、同じだった。

https://stackblitz.com/edit/attribute-style-specificity

参考

CircleCIの実行時間を3分の2くらいにした、というLTをした


CircleCIのLT会で、会社のCIをどうやって早くしたのかというLTをしてきました。 一人で全部やったわけじゃありませんが、なかなか早くなって満足している一方、もう少し余地がありそうだなとか思ってます。

増枠: CircleCI ユーザーコミュニティミートアップ 【LT会】 - connpass https://circleci.connpass.com/event/140666/

社内のKibelaには、これにどういう意味があって、エンジニアにはこういう良い影響があるんだ、というポエムを書いたんですが、そっちで満足したので自分のblogはあっさりにしておきます。

FACTFULNESSを読んだ雑感想

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣

とても良かった。

知識がある人ほど先入観で物事を判断してしまう、何故人は思い込みをしてしまうのか、思い込みを解消するにはどうしたら良いか、という解説を丁寧にしてくれる本。 著者の実体験を口語調で書いているので、読みやすい。

エンジニアにもオススメ。

データを読むとき、何も考えず平均値みるんじゃなく中央値とか最頻値とかが大事だぞ、という話とか地味に大事だと思ったり。 病気の感染拡大を防ぐために道路封鎖したら物流が止まり食糧難になり別の犠牲者を出してしまったというエピソードは、規模は比べるべくもないが、動いているシステムに手を入れることがおおいエンジニアに身につまされるものがあった。

C96戦利品

C96に行って技術書漁ってきました。

f:id:mstssk:20190812180826j:plain

Hello world カルタ

いろいろなプログラミング言語Hello worldでカルタするやつ。マストバイ。

helloworldkaruta.mystrikingly.com

妄想実行報告書

サークル妄想実行部隊さんのごった煮本。 Vue,VuexアンチパターンとかGitHub Actionsの章が目当てで購入。

booth.pm

Firestore Mastery

Firestore童貞なので買ってみた。

shiodaifuku.io

hifumiフルセット

自作キーボード初心者キット的なやつ。

riconken.bitbucket.io


会場脱出してからてくぶ買ってない事に気がついた。

GitHubリポジトリをAWS CodeBuildでビルドするためBotアカウントで連携したらハマった

GitHubリポジトリAWS CodeBuildでビルドするためBotアカウントで連携したらハマってしまった。

TL;DR

  • GitHubアカウントに対象のリポジトリの管理権限がないとWebhook設定をできないのでエラーになる

以下、凡ミスを自戒のために書き残します。

GitHubリポジトリAWS CodeBuildでCI回そうと考え設定しょうとしました。

はじめはCodeBuildからそのまま個人のGitHubアカウントでOAuth接続して弄っていました。しかし、それだとそのAWSアカウントが扱える他の開発者が、GitHubアカウントが権限のある他のOrganizationのリポジトリなどまで見えるようになってしまいます。 そこで、OAuth接続するGitHubアカウントは開発チーム共用のBotアカウントを使うことにしました。

改めて、Botアカウントを使いOAuth接続し、対象のGitHubリポジトリを選択します。 そして設定を保存しようとすると以下のエラーメッセージが表示されました。

repository not found or permission denied.

「なんでやねん。リポジトリは見えてるんだから権限ないっちゅーことはないやろ!」と東北出身の癖にエセ関西弁で驚き、小一時間悩みました。 先輩に相談しつつ弄っているとWebhookの設定のチェックを入れているときだけエラーメッセージが出ることに気が付きました。

そこでやっとBotアカウントの権限は最小限にしてあり、リポジトリの管理権限がないのでWebhook設定ができず permission denied. と言っていることに気が付きました。

Safariでinput要素にbackground:none;を指定しつつcolorで一定より薄い文字色を指定すると完全に文字が消える

雑なメモ

Safari 12で再現。PCもモバイルも。

再現のStackBlitz stackblitz.com

chrome 75 safari 12
chrome safari

あるUIフレームワークをつかっていて、inputのdisabled時のcolorを指定していたら発生してびっくりした。 UIフレームワークのdisabled時のスタイル指定がなかったので、仮に color: #ccc; を当てていたら偶然踏み抜いた不具合のようななにか。 UIフレームワークのバージョンアップで既にこのcolor指定は不要になっていたので記述をcssから取り除いて事なきを得た。

どうもinput要素にbackground:none;を指定している状態でcolorを設定したときは発色が普通より薄く表示されているような感じ。

対処案

  • 問題が発生するcss記述を削除する
  • color 指定をもっと濃い色にする
  • Appleに泣きつく