You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
dependabotだとかrenovateだとかを使ってライブラリのバージョンアップのpull requestを自動的に送ってもらう、というような機構を利用されている方が多いと思います。 常にこれらのpull requestに目を光らせておいて常に取り込み続けるというのが理想的な形・そうあるべきだとは思うのですが、ふと気を抜くとバージョンアップのpull requestが溜まっていき、pull request自身も改訂に改訂を重ねている......みたいなことが起きがちではないでしょうか。 そういった折、誰も結果を見もしないCI (i.e. GitHub Actions) だけが回り続けているのを見て「このチェックは『ライブラリアップグレード業』をやる時に手動で回せばコンピューティングリソースの削減になるのでは?」と思い、それを試したという次第です。 この記事では例として、renovate
The behavior of the bot is configured by a .bulldozer.yml file at the root of the repository. The file name and location are configurable when running your own instance of the server. The file is read from the most recent commit on the target branch of each pull request. The file may contain a reference to a configuration in a different repository (see Remote Configuration.) If the file does not e
背景 今日GitHubの中の人のLTを聞く機会があって本当のGitHub-flowを聞いてきたので 忘れない間にメモ GitHub-Flowのお約束 Masterにあるものは即座にデプロイ可能な状態に保つこと ブランチの上で必ず作業し、その生存期間を短くすること すぐにPRを作り、フィードバックやサインオフを求めること マージしたらすぐにデプロイすること 本当のGitHub-flow 中の人曰くよくマージしてからデプロイすると言っている人がいるらしい。 だが本当のGitHub-flowは違う。 本当のflowは PR作成 ⇩ 修正 ⇩ デプロイ ⇩ フィードバック ⇩ マージ らしい。 マージ前にデプロイすることでさらにユーザーに近いところでフィードバックを受けることができるとのこと。 ダメなら直ちにmasterに戻す。なので決まりごとの中にmasterは直ちにデプロイできる状態にあること
ソフトウェアのバグを見つけて質の高い修正パッチを高速かつ自動的に生成するボットが作れたら、開発者にとってこの上ない朗報であろう。スウェーデン王立工科大学の研究チームは、「リペアネーター」と呼ぶボットを開発し、GitHub上で修正パッチの作成を人間と競うテストを実施した。 by Emerging Technology from the arXiv2019.01.10 295 155 5 0 「この世で死と税金のほかに、確実と言えるものは何もない」。米国の有名な政治家であり、発明家、物理学者であったベンジャミン・フランクリンは1789年にそう記した。フランクリンが現代の世に生きていたら、その2つに「ソフトウェアのバグ」を付け加えたことだろう。 現代のコンピューター・プログラムは複雑さを増しているため、開発過程でバグが生じるのは避けようがない。そのため、バグを見つけ、修正パッチを書くプロセスは、
ProbotはGitHub Appsを作成するためのフレームワークです。 主な機能として、「GitHubのWebHookから送信された各イベントに対する処理」、「GitHubのAPI実行」を簡潔に記載することができます。 GitHubを使う上で、チームによってローカルルールがある場合があると思います。これをみんなで守るためには、例えば啓蒙活動やレビューで頑張ることも一つの方法ですが、本質的には「そもそもルールを破れない状況を作る」ことが一番大切であるように思えます。 GitHubではBotを作成することができるので、ある程度GitHubの使い方に関するローカルルールをBotによって強制的に守らせることが可能です。 本記事では、「Issueを閉じる際にはラベルとマイルストーンが設定されていなければいけない」といったルールを守らせるためのBotをProbotで作成し、Glitchにデプロイして
2月は毎日、どこかのリポジトリに1PRを投げるのを目標に作業してみました。 もちろん、1日以上かかる作業はあるのであまり強制的にやっていたわけではないけど、意識して2月は暮らしてみた感じです。 旅行中とかは毎日コミットできてないですので、強制ではなかったです。 普段は、PRを投げる時はバグを見つけて投げたり、暇だったら投げたりしています。 目的 GitHubと毎日向き合う。 結果 20PR出しました(26 - 6) たまたまこの時期、PRのオートデプロイをするbotを開発していたので、自分へのPRが6つほどあります。 PRのstorybookをオートデプロイするようにした結果、レビューがくっそ楽になったのでおすすめです— hiroppy😶 (@about_hiroppy) 2018年2月27日 粒度 docの修正やASTの操作など簡単なものから構築周りなど。 ただ、続かないので少なくとも
いざPull Requestのレビュー!と挑んだ瞬間、「ここタイポな」という先制パンチをくらうのはとても残念なことです。 また、これは指摘しているほうにとってもチェックが負担で、気が重いものです。 人間は人間にしかできないチェックに集中すべきですし、貴重なレビュー時間を誤字脱字の修正に使うのはもったいないです。そこで開発したのが、タイポの自動検知と修正を代行するBot。その名もtypotです。 chakki-works/typot こちらは先日公開がアナウンスされたGitHub Marketplaceと共に公開された、新しいGitHubアプリの形態であるGitHub Appsで作成しています(それまではWebhookかOAuthだった)。 GitHub AppsはOAuthのようにユーザーではなく、リポジトリにひもつく形態になります。そのため、管理者ユーザーがいなくなった(あるいは権限を失
皆さんこんにちは. 現在はfluctにてfluct DRという広告配信システムの開発を行っております, 大関です. GitHub上でのチーム開発では, レビューの依頼や, CIが通ったことを確認した上でのPull Requestのマージといった複数の作業が発生しますが, これらはGitHubのUIを複数回クリックする必要があり, 非常にストレスフルな作業です. 本稿では, こうした定形作業を自動化するbotとしてpopukoを開発・導入することで, 我々開発者のストレスを軽減するとともに, より堅牢かつフィードバックの多い開発が実施できるようになった事例を紹介します. GitHubでの開発はとてもクリック操作が多い 前段でも述べたように, GitHubを用いたチーム開発においては, 数多くの定形作業が存在します. コードレビューの可能な人を探してレビューを依頼する, 依頼の度に対象者をAs
deppbot ensures that your Ruby applications are kept updated, always! Based on your configured schedule, deppbot will run bundle update on your Ruby app and send the result as a Pull Request to GitHub. deppbot will also check your app periodically for any RubyGem vulnerabilities and fix it automagically. Update Your App Now Do, Don't TellYour time is precious. deppbot doesn't just tell you that yo
トレタで使っている、チャットで勤怠管理する「みやもとさん」をオープンソースでリリースしました。 https://github.com/masuidrive/miyamoto Slackの#timesheetsという部屋で、「おはようございます」と書き込みと出勤が記録され、「お疲れまでした」と書き込むことで退勤となります。「明日はお休みさせて頂きます」と書き込むと、休暇の届け出になります。 チャットで勤怠管理する最大のメリットは、オフィスに居なくても誰がいつ出勤・退勤したのか全員が分かることにあります。出退勤管理アプリは色々出ていますが、営業で直行直帰する人や、リモートワーカーなどは、帰った時間がリアルタイムでわかりにくいという欠点があります。 「みやもとさん」では、チャットでやりとりする事でみんなの見える形で出退勤が記録され「あ、帰る前にあれも!」など、ありがちなコミュニケーションがスムー
Pure Go で辞書同梱な形態素解析器 kagome を公開してみました - Qiita という記事を見て、「Goで形態素解析できれば @zenra_bot もGoで作れる!」と思い、とりあえず全裸にするやつ作ってみた。 https://github.com/sugyan/go-zenra やってることは 全裸で形態素解析をするスクリプト - すぎゃーんメモ と同じで。 Kagome が MeCab と同様に形態素解析してくれる(同じ辞書を使っているらしい)ので、基本的にはそれを使って動詞の前に「全裸で」を挟み込むだけ。 $ go get github.com/sugyan/go-zenra/cmd/zenrize $ echo 'Goを書いてます' | zenrize Goを全裸で書いてます $ cat input.txt そうだ!嬉しいんだ生きる喜び たとえ胸の傷が痛んでも 何の為に
最近はTravisCIとかCircleCIとか便利なCIサービスが増えているみたい。 いまぼくがつくってるGIFMAGAZINEでもCIサービスを利用してみようと思って、色々調べてたらwerckerというサービスが良さそう。 werckerは、 github/bitbucket対応 privateリポジトリにも対応 無料(ベータ版なのでいつ有料になるかわかりません) という特徴があります。 今回のケースでは、bitbucketのprivateリポジトリが使えて、手頃なお値段で安ければよかったのでwerckerを採用しました。 werckerを使うと、bitbucketのプライベートリポジトリ(0円)+wercker(0円)で最高に懐に優しい開発+CI環境ができます。 ではその手順。 前提 以下については事前に準備済みとします。 bitbucketへのユーザー登録 プライベートリポジトリの作
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く