awscli-allを作った

awscli-allについて

awsのクライアント全部入りのDockerイメージです

https://hub.docker.com/r/sue445/awscli-all/

github.com

作った理由

CIから AWS SAM のデプロイをしたかったんですが、AWSは公式のDockerイメージを提供しておらず、かといってCIで普通にインストールしようとすると pip install awscli aws-cli-sam だけで1分くらいかかるし、Docker Hubを見てもあまりメンテされてないのがほとんどだったのでイラッとしたので自分で作りました。

Docker Hubをaws cliで検索すると似たような名前のイメージがたくさんあって埋もれそうなので、せっかくなのでAWSの公式クライアント全部入りって感じでawscli-allという名前にしました。

全部入りにするために https://github.com/aws と https://github.com/awslabs のリポジトリを調べたんですが、awscliとaws-cli-samの他はecs-cliしかなくて意外に少なかったという感想。

余談1

https://github.com/aws/aws-cli/issues/3291 がクローズされてるのでAWSは公式のDockerイメージを作る気は無い模様。こうやって野良イメージが増えていくんやなぁ（遠い目）

余談2

この手の野良イメージは全然メンテされずに古くなっていくのが常ですが、awscli-allを含めて僕がメンテしてるDockerイメージは全部CircleCIで定期ビルドして新しいバージョンが出たらtagをpushして全自動で新しいイメージをリリースしているので、CircleCIが死なない限りは勝手にイメージがリリースされていくので安心してください。

2020/10/28追記

awscli v2であれば公式のDockerイメージが提供されてるのでそれを使うといいと思います。（samとか他のパッケージは入ってないけど）

docs.aws.amazon.com

hub.docker.com

rubicure v1.2.1で平成＆令和対応をした

先日 スター☆トゥインクルプリキュア でキュアコスモが発表されました

【スター☆トゥインクルプリキュア 】
5人目のプリキュア、キュアコスモのビジュアルを公開！
その登場と活躍をお楽しみに！

声を担当する上坂すみれさんからメッセージも届きました！https://t.co/8oMRJnpknS#スタプリ #キュアコスモ #上坂すみれ pic.twitter.com/SGr5T60SDZ

— 東映アニメーション公式 (@toeianime_info) May 30, 2019

下記のツイートを見てrubicureで令和対応の需要を感じて対応しました

ちなみにキュアコスモの誕生は、歴代プリキュア６０人目だけでなく、令和初のプリキュア誕生となります！😃💗

凄いっ！！！😆❤ pic.twitter.com/UCJ7fMRuGC

— 💜香久矢真奈💜💫 (@mana_hanahappy) May 31, 2019

GitHub

• https://github.com/sue445/rubicure/blob/master/CHANGELOG.md#v121
• https://github.com/sue445/rubicure/pull/204

サンプル

Rubicure::Girl#heisei? and Rubicure::Girl#reiwa?

Rubicure::Girl に heisei? と reiwa? メソッドが生えて、平成プリキュアなのか令和プリキュアなのか容易に判別できるようになりました

>> Cure.star.heisei?
=> true
>> Cure.star.reiwa?
=> false

まだ実装は何もないですが、 Cure.cosmo.reiwa? は true になります（します）

Rubicure::Series#heisei? and Rubicure::Series#reiwa?

Rubicure::Series にも同様に heisei? と reiwa? が生えています。

ここで注意点ですが、スター☆トゥインクルプリキュアは平成プリキュアでも令和プリキュアでもあるので *1、Precure.star_twinkle.heisei? と Precure.star_twinkle.reiwa? は両方 true が返るようになっています。

>> Precure.hugtto.heisei?
=> true
>> Precure.hugtto.reiwa?
=> false

>> Precure.star_twinkle.heisei?
=> true
>> Precure.star_twinkle.reiwa?
=> true

*1:あくまで自分の現時点での見解なので、公式からスタプリは平成（令和）プリキュアではないという見解が発表されたらrubicureでも追従します

gitlabci-bundle-update-mr v0.3.0をリリースした

gitlab.com

changelog

https://gitlab.com/sue445/gitlabci-bundle-update-mr/blob/master/CHANGELOG.md#v030

v0.3.0の新機能

GitLab CIが他のCIと比べて優れてる機能の1つにMerge when pipeline succeeds（CIが通ったら自動でMergeRequestをマージする）があるのですが、gitlabci-bundle-update-mrでも対応しました

bundle updateのMRは作りたいけど各gemのchangelogを読むまでもないような雑なアプリの場合だといちいちAcceptボタンをポチるのも面倒だと思うので、API経由でMerge when pipeline succeedsを有効にするようにしました

gitlabci-bundle-update-mr --merge-when-pipeline-succeeds

のように --merge-when-pipeline-succeeds を渡すことで有効になります。（デフォルトだとOFF）

rubicure APIを止めた

あけましておめ令和（挨拶）

https://rubicure.herokuapp.com/ で動いていたrubicure APIですが、3月くらいから毎分のようにDDosがきていてFree Dyno hoursを圧迫してたので止めました。

リポジトリは残してるので使いたい人はDeploy to Herokuで自分のアカウントで動かしてください https://github.com/sue445/rubicure_api

あと、プリキュア誕生日icalだけGitHub Pagesに作り直した（といっても https://sue445.github.io/pretty-all-friends-birthday-calendar/ のほぼコピペだけど）のでicalがほしい人はこちらをお使いください。

sue445.github.io

Rails 5.2.2.1にしたらErrno::ENOENT: No such file or directoryのエラーになった

Railsのsecurity fixが出ました

weblog.rubyonrails.org

個人アプリ2つアップデートしたんですが、どっちもRails 5.2.2だし余裕だろうと思ったら片方だけ下記のようなエラーになってちょっとハマったのでメモ。

+ ./bin/rails db:create

(snip)

Errno::ENOENT: No such file or directory @ rb_sysopen - /home/circleci/app/tmp/development_secret.txt
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/railties-5.2.2.1/lib/rails/application.rb:597:in `binwrite'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/railties-5.2.2.1/lib/rails/application.rb:597:in `generate_development_secret'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/railties-5.2.2.1/lib/rails/application.rb:430:in `secret_key_base'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/devise-4.6.1/lib/devise/secret_key_finder.rb:24:in `key_exists?'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/devise-4.6.1/lib/devise/secret_key_finder.rb:16:in `find'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/devise-4.6.1/lib/devise/rails.rb:37:in `block in <class:Engine>'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/railties-5.2.2.1/lib/rails/initializable.rb:32:in `instance_exec'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/railties-5.2.2.1/lib/rails/initializable.rb:32:in `run'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/railties-5.2.2.1/lib/rails/initializable.rb:61:in `block in run_initializers'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/railties-5.2.2.1/lib/rails/initializable.rb:60:in `run_initializers'
/home/circleci/app/vendor/bundle/ruby/2.6.0/gems/railties-5.2.2.1/lib/rails/application.rb:361:in `initialize!'
/home/circleci/app/config/environment.rb:5:in `<top (required)>'

原因

tmp/ がコミットされていなくて tmp/development_secret.txt の作成に失敗してた

今回CIがコケたアプリはRails 4.1系からupdateしてたので tmp/.keep の追従忘れてたんだろうなあと納得

対応内容

tmp/ を作ってコミットしただけ

mkdir -p tmp
touch tmp/.keep
git add -f tmp/.keep
git commit -am "Add tmp/"

Dependabotの設定ファイルを置くようにした

なにげなくDependabotを見てたらリポジトリに .dependabot/config.yml を置けることを気づいたので置いてみた

https://dependabot.com/docs/config-file/

ちなみに .dependabot/config.yml をコミットしてると設定画面でこんな表示になります

設定ファイルを置くメリット

• 新しくリポジトリを作ってDependabotを導入する時にボタンをポチらずに済む
  • 別リポジトリから設定ファイルをコピーしてくればいつもの設定が導入できる
• 設定をgitで履歴管理

いつも使ってる設定晒し

Rubyだとこれでだいたいいいはずですが他言語だと微妙に変えた方がいいかもしれないです。

# c.f. https://dependabot.com/docs/config-file/
version: 1

update_configs:
  - package_manager: "ruby:bundler"

    directory: "/"

    update_schedule: "daily"

    default_assignees:
      - sue445

    allowed_updates:
      - match:
          # Disable. Only top-level dependencies (and security patches for subdependencies)
          update_type: "all"

    automerged_updates:
      - match:
          dependency_type: "development"
          update_type: "all"
      - match:
          dependency_type: "production"
          update_type: "semver:patch"

    # Enable. Only lockfile updates (ignore updates that require Gemfile changes)
    version_requirement_updates: "off"

解説

default_assignees

PRが作られた時に誰をassignさせるか。

PRを見た後にchangelogを見に行ったりしてると実際にマージするのをちょいちょい忘れるので自分をassignしておくと便利

allowed_updates

設定画面の「Only top-level dependencies (and security patches for subdependencies)」に相当。

デフォルトだとこれに入っているんですが、そうするとGemfileに直接書かれてるgemしかbundle updateの対象にならなくて、gemの依存の依存のgemがupdateされないのでいつもこのチェックを外すようにしてます。

設定ファイルだと update_type: "all" を書けば同じ効果になります

automerged_updates

設定画面のAutomatic PR mergingに相当

個々の好みが分かれるところですが、僕は普段development dependencyのアップデートは全部自動マージして、runtime dependencyはパッチバージョンのアップデートのみ自動マージ（マイナーバージョンアップは手動）にしてます

version_requirement_updates

設定画面の「Only lockfile updates (ignore updates that require Gemfile changes)」に相当

デフォルトだとチェックが外れているんですが、そうすると Gemfile でバージョン固定していた場合にGemfileを書き換えてbundle updateするので、これにチェック入れとくことで Gemfile.lock のみ更新かけるようにしてます。

（Gemfile でバージョン固定しているのはだいたいなんらかの理由があるはずなので書き換えられるのは困る）

設定ファイルだと version_requirement_updates: "off" に相当。

まとめ

ローカルで bundle update した時と同じ挙動にしたければ allowed_updates と version_requirement_updates を書いとけばいいかと。

gitlabci-bundle-update-mrを作った

gitlab.com

rubygems.org

経緯

試験勉強を始めるとついつい部屋の掃除をしちゃいますよね？

（訳：RubyKaigiの資料の現実逃避で全く関係ないgemを作った）

どんなgem ?

名前からピンときた人もいるかもしれませんが、CircleCIで bundle update のPRを作る circleci-bundle-update-pr のGitLab版です。

使い方

0. 事前準備

READMEを参考に GITLAB_API_ENDPOINT と GITLAB_API_PRIVATE_TOKEN と OCTOKIT_ACCESS_TOKEN をEnvironment variablesに設定します

1-A. .gitlab-ci.ymlに直接書く

.gitlab-ci.yml に下記のようなものを書きます

stages:
  - build

continuous_bundle_update:
  stage: build

  image: ruby

  cache:
    key: "$CI_BUILD_NAME"
    paths:
      - vendor/bundle/

  before_script:
    # Set timezone to Asia/Tokyo
    - cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

  script:
    - bundle install --path vendor/bundle
    - bundle clean
    - gem install --no-doc gitlabci-bundle-update-mr
    - gitlabci-bundle-update-mr --user="GitLab CI" --email="gitlabci@example.com" --labels="bundle update"

  only:
    - schedules

1-B

GitLab v11.4でinclude *1がCoreに入ったので、せっかくの機会なのでincludeに対応しました。

その場合は下記のような書き方です。

include:
  - remote: "https://gitlab.com/sue445/gitlabci-bundle-update-mr/blob/master/gitlabci-templates/continuous_bundle_update.yml"

continuous_bundle_update:
  stage: build

  variables:
    # override variables (followings are defailts)
    CACHE_VERSION: "v1"
    GIT_EMAIL:     "gitlabci@example.com"
    GIT_USER:      "GitLab CI"
    LABELS:        "bundle update"
    OPTIONS:       ""

  before_script:
    # Set timezone to Asia/Tokyo
    - cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

さっきと違って変数の上書きを除けばちょっと短くなるのがポイントです。

2. スケジューラに登録する

GitLab CIでscheduler（cronのように定期実行する機能）を使うにはymlではなくリポジトリの設定から登録する必要があります

今回のgemを作るにあたって

アップデートされたgemのcompareリンクを生成する部分は前述のcircleci-bundle-update-pr同様 compare_linker を使っているので、circleci-bundle-update-prと同じ内容のMRが作れます。

gitlabci-bundle-update-mrで作ったMR

circleci-bundle-update-prで作ったPR

ただしgitlabci-bundle-update-mrから使おうとすると一部使いづらい部分があったので、汎用的に使えるように一部ロジックをpublicメソッドに切り出すPRを投げました。

github.com

*1:CircleCIのorbのように外部のymlを取り込めるようにする機能