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
こんにちは、kenzauros です。 資料をまとめたりするときに使えるかもしれない、ちょっとした小ネタです。 Git で差分のあるファイル名を抽出するには git diff を使えばいいのですが、そのファイル名を使ってごにょごにょ加工したい場合、(私は)JavaScript のほうが便利なので、 GitHub の Pull Request を利用することにしました。 やりたいこと ちなみに git diff コマンドでコミット間の変更ファイル名一覧を取得するのは下記のようにします。 diff-filter=d オプションで「削除以外」、 name-only でファイル名のみ、 origin/master と HEAD の差分を抽出します。 これでずらずらーっとファイル名が得られます。 が、このあとこの一覧を加工しようと思うとシェルスクリプトや PowerShell でごにょごにょしなけれ
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account
GitHubでは、Pull Requestのテンプレートを作ることができます。 リポジトリ用のPull Requestテンプレートの作成 - GitHub ヘルプ Pull Requestに書いてほしいことが明らかになるため、レビューする側も効率よくレビューできると思います。 このPull Requestでやったことはなにか? このPull Requestでやらないことはなにか? 動作確認は何をしたのか? 特に気になるポイントやちょっとしたモヤはあるか? 個人的に「やらないことを明記」は大事だと考えており、レビューする側が「単に忘れてるだけ? それとも後でやるつもりなの?」で迷うことが無くなるのは大きいです。 ただし、Pull Requestの粒度や内容はチームやプロジェクトの特性によってかなり異なると思います。 そこで今回は、私が以前に作成したPull Requestのテンプレートをご紹
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account
仕事でコードを書くときは大抵 pull request にしてレビュワーに見てくださいって言うことになる。 description には「これをやらないと (今のままでは) こう困る」というのを書くように意識している。 多分こんなことは本やインターネットで無限に言われていると思うけどやっぱりそうだなと思って書く。 pull request をつくった身からするとどうしても変更に意識がいきがちで、「これがやりたい」「ここをこう変えた」ということを description にまず書くのだけど、レビューする立場から見ると「今の何がいけないのか」がわからない。変更しなくて済むならそれが一番*1なので、いや〜どうしても変えないと困るんですよね、という点を理解したい。 なので、 (さっきまず書いた内容に加えて) 「今のこれが壊れてて困る」「これがやりたいけど今のこの機能だとこれが足りない」みたいなこと
This PR introduces YJIT, a just-in-time compiler built using a Lazy Basic Block Versioning (LBBV) compiler architecture. For more details about the technique, please refer to Maxime’s published paper and recorded talks: ECOOP 2015 paper: https://arxiv.org/pdf/1411.0352.pdf ECOOP 2015 talk: https://www.youtube.com/watch?v=S-aHBuoiYE0 RubyKaigi 2021 talk: https://www.youtube.com/watch?v=PBVLf3yfMs8
こんにちは。メルカリのweb platformチームの@urahiroshiです。 この記事は、Mercari Advent Calendar 2021 の9日目の記事です。 今回は、メルカリWeb版のアプリケーションの開発に利用している検証環境の実現方法について記載します。 メルカリWeb版の開発では、フロントエンドアプリケーションのリポジトリに対してPull Requestを作成すると、そのコードベースの検証環境(以下ではPR環境と記載します)が自動で構築され、変更箇所に対するマニュアルテストや自動テストに利用されています。 ステージング環境やInternalリリース(https://engineering.mercari.com/blog/entry/2019-10-30-105936/ に記載しているTrialリリースに相当します)を用いた本番環境でのテストも実施しているのですが、
この記事は、Lancers(ランサーズ) Advent Calendar 2022 の2日目の記事です。 モチベーション 一般的にPull Requestはサイズが小さいほうが良いとされていますが、理想的なPull Requestのサイズは具体的に何行なのでしょうか? また、なぜPull Requestのサイズは小さい方が望ましいのでしょうか? 本稿ではPull Requestの理想的なサイズとその理由について、リサーチした内容をまとめます。[1] 本稿で取り扱う観点について Pull Requestのサイズを考察するにあたり、主に注目される観点は以下の2つがあります。 リーン思考に基づいたフロー効率の観点 コードレビューに関する観点 本稿では、理想的なPull Requestのサイズについて具体的な数字を示したいというモチベーションから、コードレビューに関する観点について取り扱うことにし
ブランチを作成してから PR を作成するまでに発生した main ブランチの変更を取り込む必要があるケースはけっこうあります。特に規模の大きい開発ではマージの作業コストは大きくなります。マージキューの ChangeLog の文章には以下のように書かれています。 開発者はマージ前に PR ブランチを更新して、マージ時に変更が main ブランチを壊さないようにする必要がしばしばありました。PR ブランチ更新のたびに、CI によるチェックの新たなラウンドが発生し、開発者がマージを試みる前に終了する必要がありました。別の PR がマージされた場合、すべての開発者はプロセスを再度実行する必要があります。 マージキューは、マージのためにキューに入れられた各 PR がキュー内の先行する PR でビルドされるようにすることで、このプロセスを自動化します。 つまり、PR を作成したらマージする代わりにマー
【書き起こし】The World Is at Your Pull Request! – How to Make a Dynamic QA Environment on Kubernetes and Istio - Yuki Ito【Merpay Tech Fest 2021】 Merpay Tech Fest 2021は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りで、2021年7月26日(月)からの5日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。 この記事は、「The World Is at Your Pull Request!」の書き起こしです。 伊藤雄貴氏:「The World Is at Your Pull Request!」というタイトルで、メルペイの伊藤が発表
// Variadic tuple elements type Foo<T extends unknown[]> = [string, ...T, number]; type T1 = Foo<[boolean]>; // [string, boolean, number] type T2 = Foo<[number, number]>; // [string, number, number, number] type T3 = Foo<[]>; // [string, number] // Strongly typed tuple concatenation function concat<T extends unknown[], U extends unknown[]>(t: [...T], u: [...U]): [...T, ...U] { return [...t, ...u];
はじめに 初めまして。QAチームの三木と申します。 commmuneモバイルアプリのQAを担当しており、入社して7ヶ月が経ちました。 モバイルアプリチームでは、新機能開発だけでなく既存機能の改修や不具合修正を日々並行して進めています。 特に、「既存機能の改修や不具合修正」は小さい単位で行われるため、その変更起因で意図しない箇所に新しい不具合が発生する可能性があり、リグレッションテストでの確認が必要です。 現状、モバイルアプリのテストはほとんどが手動テストのため、リグレッションテストも手動で実施しています。 今回は、「意図しない不具合」をなるべく減らすために、影響範囲をどのように調べているかについて書きます。 リグレッションテストの定義 まず、リグレッションテストの一般的な意味や目的を定義します。 システムに対する修正や変更によって、意図せずに振る舞いに影響を与えることがある。 そういった意
GROWI に draw.io 連携機能を PR (Pull Request)して v3.7.0-RC としてリリースされた話JavaScriptMarkdownReactDraw.ioGrowi はじめに GROWI に draw.io 連携機能を実装して Pull Request し、無事マージされて、バージョン 3.7.0 RC(Release Candidate) としてリリースされました! (今は docker image のみ提供されてます) weseek/growi Add draw.io Integration #1685 使い方のドキュメントはこちらです。 draw.io で様々な図を作成する | GROWI Docs この記事では簡単な機能紹介と実装のモチベーション、どうやって実装したかなどをお話しようと思います。 GROWI って何? 株式会社 WESEEK が OS
初心者向けのPull Request(PR)作成方法はopensource.guideをはじめとして数多く見るのですが、もうちょっと突っ込んだというか中級的な内容の記事を読みたかったので自分で書きます。題材として主に直近で書いた大きめの機能追加用PRを使っています: github.com 修正や新機能を入れる利点を明確に伝える 何かを提案する場合、その背景には必ず動機となる利点があるはずです。これはとても単純に伝えられることもあれば、テストやグラフを作成しないと伝わりにくいものもあります。 今回の変更では、GitHub Actions workflowの定義ファイル簡素化とパフォーマンス改善が利点でした。定義ファイルが簡素化されることはドキュメントで簡単に伝えられますが、パフォーマンスは測定しなければわかりません。よってパフォーマンス検証用のリポジトリを作成し測定を行うことで、ビルド時間が
こんにちは。 AWSのアップデートをみてたらPull Request単位でのプレビューができると書いてありました。 便利そうだったので試してみたら便利だったので共有したいと思います。 Amplify Projectの作成 この機能を試す前にまずAmplify Projectをさくさく作っていきます。 フレームワークにNuxt.jsを使用してバックエンドなしのシンプルな構成で作ります。 Nuxt.jsプロジェクトの準備 まずはNuxt.jsプロジェクトを作成していきます。 $ npx create-nuxt-app sdx-amplidy-console-101 create-nuxt-app v2.11.1 ✨ Generating Nuxt.js project in sdx-amplidy-console-101 ? Project name sdx-amplidy-console-1
Shodo AI校正APIのベータ版に申し込み、利用させていただいています。Shodo、日本語校正のSaaSということで注目していて、今回のAPIベータ版の話がTLに流れてきたので申し込み、当選することができました。 日本語校正サービス・ソフトウェアは商用のものの質はやはり高く、例えば老舗ジャストシステムのJust Right!などは友人のライターが利用していて、評判の良さも聞いています。 ただ、それらはいかんせん良いお値段します。もちろん、良質なサービスに対価を払うことはやぶさかではありませんが、私のようなホビーライターからするとちょっと厳しいお値段です。 ただ、私もブログは細々と継続していて、不定期で有償の記事や執筆をお受けすることもあるため、何らかの校正サービスを使いたいと思っては常々思っていました。 その点、スポットで従量課金的に利用できるSaaSモデルであるShodoは魅力的です
Linus が Git comes with a nice pull-request generation module, but github instead decided to replace it with their own totally inferior version. https://github.com/torvalds/linux/pull/17#issuecomment-5654674 Gitにはniceな pull-requestモジュールがあるのにGitHubは劣化版に置き換えた、と言っていて I believe he's referring to git-request-pull. https://github.com/torvalds/linux/pull/17#issuecomment-5660608 それは git request-pull のことらしい
GitHub Actions便利ですよね。 ペパボではGitHub Enterprise Server(以下、GHES)が運用されており、GHESでもGitHub Actionsが利用できます。 uses: だけで利用できるリポジトリを横断で再利用可能なActionの存在はかなり生産性を上げていると思います。 そういった便利なワークフローを複数のリポジトリに対して適用していきたいことが時々あります。 一気に複数のリポジトリに同じワークフローを適用したいこともあれば、「あ、このリポジトリにはあのリポジトリのワークフローをいれたほうがいいな」となることもあります。 その時、それぞれのリポジトリに対して「突然のデフォルトブランチへのpush」はあまりにも乱暴なのでPull Requestを作成していくことになります。 ただ、適用したいレポジトリが2桁あったとき、Pull Requestを作成する
概要、背景みなさまこんにちは。フロントエンドエンジニアのはしばです。 現在までにありがたいことに複数名の エンジニアになりたい or 新人エンジニア の方のサポートを経験してきました。 その中でほぼ毎回共通して伝えていることがあったので記事にしてみました。 これから初めてチーム開発するという方も、学習開始したばかりの方にも参考になる内容かと思いますので是非最後まで見ていって下さい~ PRを出すその前に①developの更新を都度作業ブランチに反映していますか?これをやりたくない気持ち...少し分かります。僕も最初Git使うの恐怖だったので。 コンフリクトも怖いし、マージ??プル??リモート?????と最初四苦八苦しながら対応したのを覚えています。 ただ、この重要性を理解できていない === Gitを利用したチーム開発のフローが理解できていないのでしっかり挑戦しましょう。 むしろコンフリクト
OSS(Open Source Software)のコミュニティー(本家)のリポジトリにPull Requestを出す時にいつも手順が分からなくなってしまいます1。例によって調べながらやりますが、ページによって記載がまちまちだったりします。そこで備忘録として手順をまとめておくことで迷わずスムーズにPull Requestを出せる様にしておこうと思いました。また、ただGitのコマンドを羅列しただけの備忘録では無く、実際にVega EditorというOSSにコントリビュートしてみた行程をまとめて残しておこうと思います。 GitHubを例に解説しますが、その他のGitベースのサービス(GitLab, BitBucket等)も基本的に(コマンド)操作は同じです。 OSSのリポジトリをForkする 今回はVega EditorというOSSにコントリビュートしてみようと思います。たまたま今回この記事を
個人的によく使っていて時々 Pull Request も投げている Durable Functions の開発リポジトリでは、全ての Pull Request に対しては基本的なテストのみ実行し、full-ci というラベルが付いた時のみ全てのテストを実行するようになっています。 実際に以前投げた Pull Request は影響範囲の広い修正だったので、full-ci ラベルが付けられてテストを全て実行し、パスしたのを確認してマージされました。 理想的には全ての Pull Request で全てのテストを実行するべきなのでしょうが、テストに関しては時間的な制限もあって難しいので、この運用は個人的にかなり良い感じだと思っていました。 常に全てのテストを実行する必要がないことは開発中していて気が付きますし、テストに時間がかかってマージやリリースが遅れ始めるとテストが邪魔扱いされかねません。そ
GitHubのPull Requestのコメントから任意のGitHub Actionsを実行する必要があり、やり方に少々癖があったので紹介します。 issue_comment ドキュメントを眺めているとPull Requestに関連するイベントはいくつかありますが、Pull Requestのコメントをトリガーとしたイベントが無いように見えます。 pull_requestイベントはPull Requestの作成やラベル付けをトリガーとするイベント pull_request_reviewイベントはレビューされたときをトリガーとするイベント pull_request_review_commentイベントはレビューについたコメントに関するイベント どうにかPull Requestのコメントをトリガーに起動できないか調べていたらCommunity Forumで以下の投稿を見つけました。 github
謝辞 先日、こんな記事を書いた。 ありがたいことに多くの反応をいただいた。 この場を借りて御礼申し上げる。 要点 Pull Request 駆動で小説を開発する 情報整理の場としての Pull Request 校正の場としての Pull Request Pull Request 駆動で小説を開発する 小説を書いて GitHub にアップロード(コミット→プッシュ)していく中で、「こういう表現にしたほうがよくなるんじゃないか」と思いつくことがある。 GitHub ではいつでも過去のデータにアクセスして文章を取り戻せるから、大掛かりな変更や修正も気軽にできる。 だが、更新頻度の高いファイルほど、取り戻したい特定の時点を探し出す手間が増える。 コミットメッセージを記載していたとしても、同じ箇所を別の時点で修正している可能性がある。 あなたがコマンドラインを使うのに抵抗がなければ、こういった検索方
こんにちは、株式会社はてなで最近はマンガサービスのコードを書いている id:stefafafan です。この記事はMackerel Advent Calendar 2020の13日目の記事です。 qiita.com 今回はMackerelのOSSにPull Request送ったときの話をしてみます。 前提 一応簡単に前提から話すと、Mackerelというのは株式会社はてなが開発しているサーバ監視サービスです mackerel.io Webサービス本体のコード自体は公開されていないですが、監視対象のサーバにインストールされるエージェントやプラグイン、また公式ドキュメントのマークダウンなどは大体GitHubにオープンに公開されています。プラグインなどはAPIが公開されているので誰でも簡単に作れます。 github.com 今回はこの公開されているコードに対して誰でも気軽にPull Reques
This is it; the PR that converts the TypeScript repo from namespaces to modules. TL;DR: The TypeScript compiler is now implemented internally with modules, not namespaces. The compiler is now 10-25% faster. tsc is now 30% faster to start. Our npm package is now 43% smaller. More improvements are in the works. If you're reading this and the 5.0 beta is out, now that the above results were as of thi
どうも! テクニカルディレクターのおきくです。 本日は、普段BiTT事業で実際にCODYメンバーに実施しているGitHubやAsanaを使ったディレクション方法についてまとめました。この記事が少しでも皆さんの参考になれば嬉しいです。 ここでお話する内容は、自分のGitHubプロジェクトにもなりますが、以下GitHubのリポジトリにフォーマットとしてまとめています。もしよければこちらも参考にしてください。 チケットの書き方のポイント(エンハンスメント、新規機能作成時) フォーマットはこちらから。 ポイント① 1チケット = 1PRの粒度でまとめましょう これは世界共通のルールなので、いわずもがなでしょうか。基本はグローバルスタンダードなルールに則って行いましょう。 ポイント② 概要をしっかりとまとめましょう メンバーに何のためにどうしてこのチケットが発行されているのか、どんなタスクなのか全容
[Fix #47600] Motivation / Background This Pull Request has been created because we identified a need to improve password length validation for BCrypt compatibility in the ActiveModel::SecurePassword module. The current validation only considers the character count, which may not accurately reflect the byte size limit imposed by BCrypt. Detail This Pull Request changes the password length validatio
Comments on individual commits made outside a pull request no longer appear in the pull request timeline pull-requestsrepositories August 4, 2022 Code review on GitHub has evolved a lot since we introduced the ability to comment on an individual commit in 2008. Users today can propose a change using a pull request, which provides a first-class experience for reviewing, discussing, evolving, and ul
Dependabot のPull Request(以下PR)が作られた際に開始したGithub Actionsワークフローが Secrets を参照できずに失敗していたので原因を調べてみました。 2021/3/1から適用になった以下のUpdateが影響していて、 Dependabot から実行される Github Actionsワークフローは読み取りだけが可能な GITHUB_TOKEN のみ使うことができ、いかなる Secrets も使えなくなるという変更が原因でした。 github.blog なので、例えばpushイベントトリガーで実行されるワークフローの中で Secrets として追加しておいたPersonal access tokensを使って、取得したカバレッジのサマリをコメントで追加したり、自動でラベルを追加するといった書き込み(write)権限が必要な場合は、ワークフローが落
はじめに Pull-Request にコミットが追加されると bot がコメントをする という GitHub Actions のワークフローを書きました。 実行結果 ワークフローのサンプル 次のように記述しました。 2022 年 1 月 24 日追記:https://cli.github.com (gh コマンド)を用いたシンプルな実装に置き換えました。 name: comment_on_pr on: pull_request: types: synchronize jobs: comment: runs-on: ubuntu-latest steps: - name: Create comments run: | cat << EOF > comments 1st 2nd 3rd EOF - name: Post comments env: GITHUB_TOKEN: ${{ secre
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く