こんにちは。kanekoです。 アクトインディでは評価制度の一環で半期ごとに各自が目標を立てます。 4月から社員になったので私も初めてエンジニアとしての目標を立てました！ そのうちの一つがgemなどのアップデートの自動化です。 そしてこの度、Dependabotを導入しました。 Dependabotはライブラリーの更新をチェックしてくれ、しかも変更をPull Requestにしてくれるとてもいい子です。 少し前にGitHubが買収したことで話題になりました。 Dependabotに限らず、すでに何かしらの仕組みを導入している方は多いと思いますので、「Dependabotでこうしてみたよ！」ということに加え、大きなサービスで導入するに当たって感じたことも言語化してみます。 私のように、経験値が低くて何するにもドキドキする！という人の参考になれば幸いです！ 導入するまで Dependabotを
TL;DR Although apps and gems look like they share the concept of "dependency", there are some important differences between them. Gems depend on a name and version range, and intentionally don't care about where exactly the dependencies come from. Apps have more controlled deployments, and need a guarantee that the exact same code is used on all machines (dev, ci and production). When developing a
どうも、バックエンドエンジニアのサトウリョウスケです ✌︎('ω')✌︎ 若干釣り臭いタイトルですが、先日 RubocopChallenger という gem の v1.0.0 をリリースしたので紹介させて頂きます 🙏 github.com 経緯 僕が所属している ソーシャルPLUS は 2012 年頃から開発が始まりました。Rails のプロダクトとしては古株の方だと思います。 ソーシャルPLUS に RuboCop が導入されたのは 2017/02 頃 1 で、それまで特に RuboCop を意識したコードで開発を進めてこなかったので、巨大な .rubocop_todo.yml が出力され、それが手付かずのままになってしまっていました。ちなみに当初は 1669 行 195 種類 の違反ルールがありました。 このままでは RuboCop の恩恵が受けられないので、 RuboCop Ch
circleci-bundle-update-prとは CircleCIでbundle updateしてPRを作るgemです。（id:masutaka26 氏製作） github.com モチベーション コアの処理はgemになっていてCircleCIから呼ぶ部分は実質ワンライナーなのでorb化不要な気もしましたが、あるとそれなりに便利そうなので作ってみました 使い方 だいたいこれで動きます。 version: 2.1 orbs: ruby-orbs: sue445/ruby[email protected] workflows: version: 2 nightly: triggers: - schedule: cron: "00 10 * * 5" filters: branches: only: master jobs: - ruby-orbs/bundle-update-pr: image: "
tachikoma gemはdeprecatedです! tachikoma.ioはもうちょっとだけ続くんじゃ。さねまつです。 Rails Developers Meetup #4にご参加いただきありがとうございます。会場提供しました。そこで、Bye, tachikoma gemというLTをしました。 重要 tachikoma gemはdeprecatedです! tachikoma.ioはもうちょっとだけ続くんじゃ あとは思い出話です。 tachikoma gemが解決したかった問題 しょっちゅうbundle updateしていかないと、つらい。もうバージョン上げられない。あるある。 昔ならともかく、最近はみんなわかってる。いろんな脆弱性もでるし。わかってなかった人はわかって持って帰ってください。ただ、結構めんどくさい。 tachikoma gem bundle updateしてpull r
Ruby ユーザーに朗報です！ 私たち Google は先ごろ、google-cloud-gemserver gem をリリースしました。これにより、お客様はプライベートな gem サーバーを Google Cloud Platform（GCP）に 1 つのコマンドでデプロイできます。 これは、プロプライエタリなビジネス ロジックを含むライブラリを作成している企業や、パブリック ライブラリを社内で使用するためにミラーリングしている企業にとって大きなメリットです。 こうしたライブラリは、Ruby では gem と呼ばれます。最近まで、gem の優れたホステッド ソリューションは存在しませんでした。そのため、特に Ruby では、多くの開発者が独自のカスタム ソリューションを構築したり、Gemfury のようなサードパーティに頼ったりしていました。 GCP で gem サーバーを運用することに
課題 gemのバージョンが古くなったままになっていたまま放置されていた。 ときどき、個別にbundle updateしていたが、もっと小まめにやりたい。 どうせなら勝手にやって、問題があるときだけ教えてほしい。 調査 ありがたいことに、ci-bundle-updateというHerokuアプリと、circleci-bundle-update-prというgemが存在しました。 ci-bundle-update ci-bundle-updateはHerokuアプリ。 Herokuのアプリといっても、Web用の画面はなく、コマンドラインのみ。 Heroku Schedulerを使って、cronのように1日1回Circle CIに該当リポジトリのNightly buildを依頼するという役割のみ。 ci-bundle-update 上記のリンクからDeploy to Herokuボタンを押して、適切
RubyKaigi 2016 の後の移動中に hsbt さんに bundled gem と default gem との違いについて聞いてみた話をまとめてみました。 違い bundled gem は単なる gem で gem uninstall もできる普通の gem default gem は uninstall できない bundler の clean_env 環境でも見える bundler で別のバージョンを指定してインストールしていれば、通常の bundler の load path の挙動に従って、そちらが使われる たとえば ruby 2.3.1 だと lib/ruby/gems/2.3.0/gems/rdoc-4.2.1 に bin/rdoc と bin/ri しかなくて他は lib/ruby/2.3.0/rdoc* などの標準添付のところに入っている というような違いだと聞き
先週のRubygems.orgの脆弱性報告を受けてgemを作りました github.com 脆弱性の詳細 使い方 自分がリリースしたgemのうち攻撃を受けた可能性があるgemを検索 Rubygems.orgに上がっているgemとリポジトリに上がってるソースコードの差分を調べる 既知の問題 まとめ 脆弱性の詳細 RubyGems.org gem replacement vulnerability and mitigation - RubyGems Blog （翻訳）RubyGems.orgでgemが置き換えられる脆弱性とその緩和策について - Qiita gemの名前にダッシュが含まれるもので（例：'blank-blank'）、2014年6月11日以降、2015年2月8日以前にアップロードされたものは攻撃を受けている可能性があります。（2015年2月8日から2016年4月2日の間にアップロー
こんにちは、金子です。 普段はRailsを書いたりしています。 今回は2016/4/6に発表された、RubyGems.orgの脆弱性についてまとめました。 脆弱性について RubyGems.org gem replacement vulnerability and mitigation をざっと読んでみると、 特定の状況で、RubyGems.orgにupdateされているファイルの内容が不正に書き換えられる可能性があった 特定の状況とは、2014-6-11から2016-4-2までの間に登録されたgemのうち、'blank-blank'のように名前に'-' (dash)が入っているもの ただし2015-2-8以降に登録されたgemはRubyGems.orgがsha256 checksumを計算しており、それと実際のファイルの突合をして、書き換えられていないことを確認ずみ つまり、2014-6
はじめに この記事は2016年4月6日に公開された RubyGems.org gem replacement vulnerability and mitigation の日本語訳です。 内容を見る限り、この脆弱性が実際に悪用された可能性は低そうですが、念のためgemの開発者やgemの利用者は一読しておくことをお勧めします。 翻訳の方針について 筆者はgem開発やセキュリティ問題にそこまで詳しくないため、一部翻訳に怪しいところがあるかもしれません。 また、翻訳は日本語としての読みやすさを重視してところどころ意訳しています。 もし完全に間違った訳になっていたり、意訳しすぎて原文のニュアンスが変わってしまったりしているところがあれば、コメントや編集リクエスト等でやさしく指摘してやってください。 原文： RubyGems.org gem replacement vulnerability and
日々、bundle updateしてますか！ circleci-bundle-updateとcircleci-bundle-update-prを使って、bundle updateの Pull Requestを自動化する手順をまとめてみます。作者の記事を読めばいいっちゃいいんですが、地味に抜けていた手順と各ステップは何のために必要かを整理してみました。 このgemは、Pull Requestに各gemの差分リンクを貼ってくれるのが便利だな！って思って採用してます。素敵なgemをありがとうございます。 github.com github.com ステップは CircleCI経由でbotからgithubにpush出来るようにしておく CircleCI経由でbotからgithubにPR作れるようにしておく 外部からCircleCIへbuild指示できるようにする 外部からcronでCircleCI
working = Delayed::Job.where('locked_at IS NOT NULL').where(last_error: nil) # 再試行分は取れない… failed = Delayed::Job.where('last_error IS NOT NULL') pending = Delayed::Job.where(attempts: 0, locked_at: nil) enqueued = Delayed::Job.all - failed 実行中ジョブ(working) 起動しているWorkerの数だけジョブが実行される。 実行されるとlocked_at, locked_byがセットされる。 失敗ジョブ(failed) 実行中ジョブが失敗すると、last_errrorにその失敗内容が、failed_atにその時刻が保存される。 この時attemptsが1増
二年前に autodoc を導入したが、現在はもはや誰も見てないし使ってないね、という話を社内でしたら、「使い始めた話だけじゃなくて、やめちゃった話もブログに書くべき」と指摘され、確かに誠実な姿勢とはいえないなと反省したのでこの記事を書いています。 恥を忍んで現状を明かすと、 master ブランチに push されたタイミングで実行される Jenkins のジョブが半年ずっと fail していた、ということに昨日気づいた体たらく。そもそも生成された markdown ドキュメントを push していたリポジトリがとっくの昔に削除されていたと思っていた。 うまくいかなかった原因の分析: Quipper の Internal API は非常に込み入ったデータ構造を返すものがほとんどで、お世辞にも「きれいな RESTful API」とは言えない。なので request spec を書く際に、完
■ [ruby] gemを作るときに実行ファイルをbin/以下ではなくexe/以下に置くことについて 例えばあなたがコマンドラインからピザを注文するようなRubyGemsを書いているとすると、今まではbin/order_pizzaに実行用のファイルを置いていたと思うけど、それがexe/order_pizzaに変わるかもしれない、という話。 仕様変更なの？ 実行ファイルをどこに置くかというのは完全に慣習の話で、.gemspecの仕様上は好きなところに置けるようになっている。なので既存のgemが動かなくなるという話ではない。 ただbundle gemコマンドでgemを新規生成したときに、以前のBundlerでは.gemspecが以下のようになっていたのに対し、 spec.bindir = "bin" spec.executables = spec.files.grep(%r{^bin/}) {
去年 compare_linker という Gem を作り、 RubyKaigi で発表もしたが、作って力尽きてしまった感があった（その後このプロジェクトは masutaka さんが引き取った）。 そもそもやりたかったことは「Gem のバージョンを比較して Diff を読むのを楽にしたい」ということで、そういうのを実現するツールは他にもちらほら見かけてきたもののちゃんと試してなかったな、と思いだして、というか Ruby Weekly にそういうのが一個載ってたので、少し調べた。ので忘れないように（むしろ忘れてもいいように）メモ。 fedora-ruby/gem-compare · GitHub メタ情報の差分しか表示されず、ソースコードの Diff が読めないのでいまいち。 teeparham/gemdiff · GitHub これはだいぶやりたかったことに近い。 compare_link
tl;dr Cron for GitHubで定期的にCIサーバーのフックを起動する CI側では、特定のブランチの場合のみ起動するスクリプトを用意する 自分のやりたい操作をして、git_httpsable-push, pull_request_create でPull Requestを送る 定期的にDependency UpdateのPull Requestを送る フックの起動 Cron for GitHubのschedulerはこのように設定した。 bundle exec cron-for-github clear --slug=metarubygems/carrion_crow --namespace=cron_for_tachikoma --verbose && bundle exec cron-for-github ping --slug=metarubygems/carrion_c
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
