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
コードレビューでいちいち「フォーマッターが適用されていない」と指摘するのが煩わしい、スペースやら{}の位置とか表面的なレビューよりもビジネスロジックやセキュリティ面などの本質的なレビューに時間を割きたいそこのあなた! GitHub Actionsを使ってフォーマット指摘してもらいましょう。 PHPでやっていますが各言語で提供されてるフォーマッターを同じような感じで使えると思います。 やること- Pull Requestが来たらGitHub Actionsを動かす - GitHub Actionsでphp-cs-fixerを動かす - php-cs-fixerでフォーマッター未適用ファイルを検出する - 検出したらマージできないようにする やらないこと- 変更箇所のみの未フォーマット検知 - 未フォーマット箇所の表示 - 自動修正 GitHub Actionsの準備下記リポジトリの .git
きっかけ 社内で使っている pull request のテンプレートがあり、各人でブックマークレットや、Using saved replies などを利用してテンプレートを適用しているのですが、テンプレート原本の内容がちょいちょい更新されるので、人によって使っているテンプレートが古いままだったりすることがありました。 それを解消する方法はないものかなーと思っていたところ、GitHubのIssue・Pull Requestのテンプレート機能を使おう の記事を見つけました。 問題自体はこれで解決しましたが、ふと pull request のテンプレートを複数使いたい場合はどうすればいいんだろう?という疑問が浮かびました。調べてみたところ公式に書いてありましたので本日はそれをまとめてみたいとおもいます。 ※なお、今回は pull request に話を限定します。 テンプレートが1つだけでいい場
bulldozer bulldozer is a GitHub App that automatically merges pull requests (PRs) when (and only when) all required status checks are successful and required reviews are provided. Additionally, bulldozer can: Only merge pull requests that match certain conditions, like having a specific label or comment Ignore pull requests that match certain conditions, like having a specific label or comment Aut
Since announcing the start of the new React documentation effort, we’ve been busy writing the content and building a custom website designed around the learning experience. We are now ready to share this early preview of what we’ve created so far to get your feedback. This early preview is deployed at beta.reactjs.org and is in active development. Please leave any feedback in #3308. TLDR Visit the
React Add <React.Profiler> API for gathering performance measurements programmatically. (@bvaughn in #15172) Remove unstable_ConcurrentMode in favor of unstable_createRoot. (@acdlite in #15532) React DOM Deprecate old names for the UNSAFE_* lifecycle methods. (@bvaughn in #15186 and @threepointone in #16103) Deprecate javascript: URLs as a common attack surface. (@sebmarkbage in #15047) Deprecate
Note: This PR initially was titled: Introduce support for ActionView::Component. I've updated the content to better reflect the changes we ended up shipping, to use the new name of GitHub's library, ViewComponent, and to remove mentions of validations, which we no longer use. - @joelhawksley, March 2020 Introduce support for 3rd-party component frameworks This PR introduces structural support for
ProductGitHub Actions improvements for fork and pull request workflowsToday GitHub Actions shipped a series of features designed to improve your workflows when working with PRs from repository forks. New settings for private repository forks Many GitHub customers choose… Today GitHub Actions shipped a series of features designed to improve your workflows when working with PRs from repository forks
With this PR we introduce optional declaration site variance annotations for type parameters of classes, interfaces and type aliases. Annotations take the form of an in and/or out keyword immediately preceding the type parameter name in a type parameter declaration. An out annotation indicates that a type parameter is covariant. An in annotation indicates that a type parameter is contravariant. An
はじめに 今すぐできるレビュワーに優しいPull Requestをつくる7つのポイント 1. WhyとWhatをそれぞれ記載する 2. 説明文は構造化する 3. コミットは課題を解決した単位で行う 4. Pull Requestは適切な大きさに分割する 5. 個別説明が必要な箇所は積極的にコメントをつける 6. テストを書く 7. Pull Requestでのコメントを Slack に通知させる さいごに はじめに はじめまして。DELISH KITCHEN開発部の桝村です。DELISH KITCHENのWEBフロントやAPIサーバーの開発等に携わっています。 突然ですが、みなさんは本日もPull Requestを使ってレビュー依頼しましたか?もしくは、誰かからレビュー依頼を受けましたか? チーム開発におけるコードレビューというものは、プロダクトの品質向上やチーム内での知見共有に貢献してい
ProductGet more information at a glance with issue and pull request linkingNow, anyone can connect an issue to a pull request from the issue directly using the new linked pull request section providing greater context to your workflow. It takes a lot to build great software, and as your team grows it can be difficult to communicate what work is coming, what’s in progress, or nearly completed. Upda
現代のWebアプリケーションはいかにmainlineにコードをmergeしてリリース頻度を高めるかが重要です。 これをチームで実現するには「いかにmergeされやすいPullRequestを作るか」がポイントになります。 レビュアーの負担を最小化する コードを書く時間もさることながら、チーム開発では「レビューを待つ時間」がリリース速度に大きく影響します。 リリースサイクルを速くするには、 レビュアーに早く見てもらうこと コメントをやり取りする回数と時間を最小化すること が重要です。 ひとつのPullRequestにはひとつの目的 PRはひとつの目的を達成するものにしましょう。タイトルを付ける時に「◯◯と××をする」みたいになったら見直しのサインです。 基本は「ひとつの目的を達成するための最小の差分を提供する」です。 複数の目的を混ぜるとレビューしづらくなるのもさることながら「◯◯の変更はい
Add a function, util.parseArgs(), which accepts an array of arguments and returns a parsed object representation thereof. Ref: nodejs/tooling#19 Checklist make -j4 test (UNIX), or vcbuild test (Windows) passes tests and/or benchmarks are included documentation is changed or added commit message follows commit guidelines Motivation While this has been discussed at length in the Node.js Tooling Grou
無視する semver の種類をversion-update:semver-major、version-update:semver-minorまたはversion-update:semver-patchで指定。 Specifying dependencies and versions to ignore - Configuration options for the dependabot.yml file - GitHub Docs このうちupdate-typesを使えば、メジャーバージョンを更新する Pull Request の自動作成のみを抑制することができそうです。 試してみた dependabot.yml ファイル ignore.update-typesでversion-update:semver-majorを指定します。 dependabot.yml version: 2 up
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
Authoring Pull Requests#1. Keep em smallIt is an art form to keep Pull Requests (PRs) small. It’s very tempting to rewrite, refactor, boy scout and reformat the code as you develop but in general, the best developers resist the temptation to change everything at once. They stay on target and get the job done with minimal code changes. Some even compete to have the highest ‘lines deleted’ to ‘lines
何故 Pull Request(以下、PR) を分割するのか? レビュアーを疲弊させないため 自分が疲弊しないため レビューの精度/速度を上げるため PRを分割しないと、何が起きるのか 時折、それなりに規模の大きな機能を実装する必要がでてきたり、当初はそこまででもないと思っていたが、いざ実装し始めてみたら色々必要になり、結果大規模な作業内容になった、というケースが出てくる。 そうした状況で、諸々の作業内容をまとめて一つのPRとして作成すると、一旦どんな問題が起こるか。 以下、レビュアー/レビュイーの視点からまとめてみる。 レビュアーの視点から 1. 追加/変更ファイル数が多い 単純に圧倒される ファイル変更に伴う依存関係のチェックが大変 どこからどこまで変更が入ったのか、影響範囲がどの程度か、把握が大変 2. diffの量が数百行有って辛い 単純に死ぬほど見づらい diffが多いと目が滑る
イントロ 唐突ですが8月中頃ヘルニアになりました。 10日間立てなかったですし未だ歩くのが遅いです。どれくらいかというと80代ほどのおじいちゃんとどっちが早く歩けるか歩道で競い合ってます。 なので身の回りのお世話をお願いすることが多かったんですが、代わりに何かをしてもらうって結構大変でした。 取って欲しい物と見られちゃマズい物が混在する棚から物を取ってもらう(ハラハラする) 引き出しにあるはずなのに、開けて見たけどないと主張される(いや絶対にある) アプリケーションで使うデータの Pull Request を代わりに出してもらいたいのにできない じゃあ GAS からサクッとできるようにしよう! モチベーション アプリケーションで使用するデータ(マスターデータなど)をエンジニア以外の人間が更新できると便利な場面て結構ありますよね。 ソシャゲで言えば日々追加されるモンスターやアイテムなど、更新
この記事は Google Cloud Advent Calendar 2023 (通常版) の 12/6 の記事です。 Cloud Run はコンテナ アプリをサーバーレス で実行するためのプロダクトですが、統合されている機能を利用せずに、単にアプリ基盤として利用するだけではもったいありません。今回は開発用途、また CI/CD を応用する例を考えてみたいと思います。 要約 ソースコード管理として GitHub を利用し、CI/CD 経由で Cloud Run へアプリをデプロイするフローを応用して、Pull Request 毎にアプリを確認できる URL を作成するフローを作ってみたいと思います。GitHub 以外でも可能ですが、今回の例では GitHub Actions を一部利用しています。 全体のアーキテクチャは以下のようになります。 サンプル コードはこちらにあります。 gclou
This implements support for the Stage 3 Decorators proposal targeting ESNext through ES5 (except where it depends on functionality not available in a specific target, such as WeakMaps for down-level private names). The following items are not currently supported: --emitDecoratorMetadata, as metadata is currently under discussion in https://github.com/tc39/proposal-decorator-metadata and has not ye
こんにちは。MIXI 開発本部 SREグループの riddle です。 以前 Flutter on the Web と WidgetBook をGCSを使って Pull Request 単位にセキュアに公開する | MIXI DEVELOPERS という記事を書きましたが、今度は Cloud Run で似たことをやってみます。 単に Cloud Run を Pull Request ごとに作るのは簡単ですが、Identity-Aware Proxy を使うところが難しいのでそこに焦点をあてて紹介します。 <目次> 作った全体の構成仕組み 2.1 Developer が https://XXXXX.example.com にアクセス 2.2 Identity-Aware Proxy が Developer の認証を行う 2.3 Nginx による Cloud Run へのリバースプロキシ 2
Adds Incremental Static Regeneration! Related issues #804 #995 Add unit tests for regeneration logic Test assumptions around how rollup.js bundles dynamic imports as per @dphang's comment Add e2e tests for ISR fallbacks Setup deployment of infra via serverless Add e2e tests Make code for ISR possible to be agnostic to the provider as per @dphang's comments Only pass what's needed to the queue as p
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 をまとめてくれる Grouped version updates for Dependabot が公開ベータとなりました こんにちは、CX事業本部 Delivery部の若槻です。 Dependabot version updates を使用すると、リポジトリ内で管理している依存関係のアップデート対応を自動化することができます。 先月のアップデートで、version updates によりオープンされる Pull Request をグループ化する機能(Grouped version updates)が公開ベータで利用可能となりました。 これにより、今までは更新対象のパッケージが多い場合は Pull Request が大量にオープンされたり、依存関係の解決でコンフリクトが発生する場合がありましたが、Grouped version updates によりこれらの問題を解
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く