Pull requestのタイトルや説明文を書いている時、「これ絶対AIでできるよな」と感じたことがある開発者は少なくないと思います。 もちろん変更の経緯や背景など、コードの差分からは読み取れない情報もありますが、コードの差分からわかることはAIが書いてくれるといいですよね。 この願いを叶えてくれるのがCodiumAIが提供しているPR-Agentです。GitHub Actionで実行でき、OpenAIはもちろんAzure OpenAIやAmazon Bedrockも使えます。 PR-Agentはすでにいろいろなところで取り上げられています*1 *2 *3ので、このブログ記事では、これまでにあまり紹介されていないPR-AgentでLLMとしてAzure OpenAIで使う方法と、使ってみた感想を紹介します。 どうしてPR-Agentを使うのか コードレビューをできるAIエージェントはいくつ
こんにちは。 DBRE チーム所属の @hoshino です DBRE(Database Reliability Engineering)チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE チーム発足の背景やチームの役割については「KTC における DBRE の必要性」というテックブログをご覧ください。 この記事では、DBREチームが運用しているリポジトリに PR-Agent を導入した際に、どのような改善が見られたかについてご紹介します。また、プロンプトを調整することで、コード以外のドキュメント(テックブロ
GitHubでは削除されていたりプライベートに設定されていたりするフォークやリポジトリに誰でもアクセスでき、さらにその動作が欠陥ではなく仕様通りであるとオープンソースセキュリティ企業のTruffle Securityがブログに投稿しました。 Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co. https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github GitHubでの一般的なワークフローとして、「新しいフォークを作成する」「コミットする」「フォークを削除する」というものを考えてみます。 この時、削除したはずのフォークの中身を誰でも確認できてしまうとのこと。
GitHub-hostedライクにAmazon ECSとAWS Lambdaでself-hosted runnerを管理するツールを作った 2023/12/04 / whywaita / 0 Comments こんにちは、whywrite.it CI班のwhywaitaです。 この記事は AWS Lambda と Serverless Advent Calendar 2023 4日目の記事です。 普段は株式会社サイバーエージェントという会社でGitHub Actions向け self-hosted runner 基盤の開発者兼PdMをやっています。業務としてはプライベートクラウドと呼ばれる社内向けのクラウド基盤を開発しつつ、その上で稼働する安価に拡張性の高いCI基盤を提供しています。 そこで利用しているコアソフトウェアが whywaita/myshoes です。GitHubから送信されるw
2023.05.26 CI/CD Test Night #6 開発者体験を改善し続けるための Self-hosted runner 運用基盤 クックパッド株式会社 技術部 SRE グループ Takamasa Saichi (@s4ichi) © 2023 Cookpad Inc. About me ● Takamasa Saichi / 齋地 崇大 / s4ichi ○ https://s4ichi.com ○ https://twitter.com/s4ichi ○ https://github.com/s4ichi ● クックパッド株式会社 技術部 SRE グループ ● 業務/関心事 ○ CI/CD(基盤, DX) ○ アプリケーションの Observability ○ パフォーマンスチューニング ○ プログラム言語処理系 © 2022 Cookpad Inc. 2 https://s
はじめにみなさん、GitHub Actionsは利用していますか。 先日、Github actionsのコストパフォーマンスについて検討していた以下の記事が少し話題になっていました。 この記事のデータによると、単純な料金の比較ではFargate Spotを利用してセルフホストランナーを起動するのが圧倒的にコストが低くなるということがわかります。 2022年12月現在、Fargate SpotはEKSに未対応で対応していないため、利用するためにはECSでないといけません。そのため、EKSでオートスケールするので有名な actions-runner-controller ではFargate Spotは利用できません。 そこで思いつきました。ECS上でFargate Spotを利用してオートスケールする仕組みを作れば、より安くセルフホストランナーを利用することができるのではないか、と。 初めにE
GitHub Actions お手軽に使えて便利ですよね GitHubでランナーが用意されているので、リポジトリにジョブの定義を置いておくだけでテストなど動かせます。 しかし... コストやセキュリティの関係で、セルフホストランナーを使う必要もあります。 となると、ランナーマシンを立てる必要が出てしまいますし、オートスケールするためには、actions/actions-runner-controller などでkubernetesの構築が必要になるかもしれません。 せっかくお手軽なGitHub Actionsなのにランナーマシンのメンテナンスが必要になるのは面倒です。 今回はセルフホストランナーをAWSのFargat、CodeBuildで上にサーバーレスで構築する方法をご紹介します。 基本的にこちらの記事をそのまま参考にしています。 (素晴らしいシステムです。詳細をお伺いしたい!) 全体の
こんにちは。サイボウズ株式会社 生産性向上チームの平木場です。 僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。 本記事はその時のネタをまとめたものです。 2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。 今週は 2024-05-01, 2024-04-24 合併号です。 今回が第 150 回目です。過去の記事はこちら。 news 📺 AWS CodeBuild がマネージド型の GitHub Action ランナーのサポートを開始 AWS CodeBuild がマネージドな GitHub Actions のセルフホストランナーを提供するようになりました。 GitHub Actions のジョブ要求時に
『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本? GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/
GitHub、「Copilot Workspace」テクニカルプレビューを開始。ほとんど全ての開発工程をAIで自動化 テクニカルプレビューは上記のCopilot Workspaceのページからウェイトリストボタンをクリックして申し込みます。 Copilot Workspaceはほとんど全ての工程を自動化 Copilot Workspaceは、自然言語で書かれたIssue(課題)を基に、Copilotが仕様案と実装計画を示し、コーディングや既存のコードの修正を行い、ビルドをしてエラーがあればデバッグも行うという、プログラミングのほとんど全ての工程をCopilotが自動的に実行してくれる、というものです。 人間は各工程でCopilotから示される内容を必要に応じて修正するか、そのまま見守ることになります。 GitHub CEOのThomas Dohmke(トーマス・ドムケ)氏は、Copilot
春の入門祭り2024の2記事目です。 Gitは、出自としては1週間で作られたLinuxカーネルのための分散バージョン管理システムでした。当時のワークフローに合わせてパッチをテキスト化してメールに添付できるような機能だったりが備わっています。 一方で、現代のGitは、デファクトスタンダードなバージョン管理システムになりLinuxカーネル以外のアプリケーション開発で利用されています。分散バージョン管理ではあるものの、サーバー・クライアント型の使われ方をしていて、GitHubやGitLabを核にして、ローカルで作ったブランチをpushして、Pull Requestの形にして管理しています。少なくとも周りで見る限りでは、それ以外の使われ方の方が少なくなってきてます。そんなこんなで求められている使われ方が変わってきていて、それに合わせた機能がぼちぼち増えています。それを活用することで、ウェブ画面上で
こんにちは。こんばんは。 開発生産性の可視化・分析をサポートする Findy Team+ のフロントエンド リードをしている @shoota です。 Findy Team+はエンジニア組織の開発生産性を可視化し、開発チームやエンジニアリングメンバーのパフォーマンスを最大化するための支援をしています。 そして(当然のことながら)Findy Team+ を作っている自分たちも、チームや個人でドッグフーディングをして、チームや自分自身の働き方やエンジニアリング組織の健康チェックをしています。 今回はそんな Findy Team+の開発チームのうち、フロントエンドチームがどのような開発環境・開発インフラで働いているかの概要をご紹介したいと思います。 フロントエンド技術スタックとCI高速化 技術スタック まずはじめにフロントエンドの技術スタックを簡単に紹介します。一般的なSPA構築の技術スタックを採
GitHub Actionsでは依存パッケージやビルド結果などをうまくキャッシュすることで、テストやビルドの時間を短縮できます。 actions/setup-nodeやactions/setup-javaなどの各言語のオフィシャルアクションは各パッケージマネージャーのためのキャッシュ機構を提供していますし、actions/cacheを使って任意のファイルをキャッシュすることもできます。 これらは内部で@actions/cacheパッケージを使っており、キャッシュの機構はGitHub自身の機能と密に結びついています。 しかし、GitHub Actionsのキャッシュはリポジトリごとに10GBまでという制限があり、開発者の多いリポジトリではsetup-nodeのキャッシュだけでもすぐに上限に達してしまいます。 私の所属するチームのリポジトリはGitHub Enterprise Serverにホ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く