GitHub、数クリックで話題の生成AIモデルを試せる「GitHub Models」を発表:「全ての開発者がAIエンジニアになれる」 GitHubはAIアプリ開発支援サービスの「GitHub Models」を発表した。Microsoft、OpenAI、Meta、Mistralなどの人気のあるプライベートモデルやオープンモデルを数回のクリックとキー操作で実験、比較、テストできるという。
![GitHub、数クリックで話題の生成AIモデルを試せる「GitHub Models」を発表](https://cdn-ak-scissors.b.st-hatena.com/image/square/0f052382ebce1cb4a9028d0e0d013342a2434f6d/height=288;version=1;width=512/https%3A%2F%2Fimage.itmedia.co.jp%2Fait%2Farticles%2F2408%2F21%2Fcover_news060.jpg)
GitHub Actions の実践的なノウハウが凝縮されている一冊「GitHub CI/CD 実践ガイド」を読んだ📕 本書ではソフトウェア開発ライフサイクルから GitHub Actions 基礎トピック・GitHub Actions 実践トピックが紹介されていて,さらに GitHub Actions を活用して実現するリリース自動化・パッケージ管理・セキュリティのシフトレフトまでもカバーされている❗️素晴らしい👏 GitHub Actions をなんとなーく使っていたり,いつも既存のワークフローをコピーしていたりする人は必読かなと \( 'ω')/ また著者の経験に基づくベストプラクティス(こうすると良いよ〜的な)が散りばめられているのも現場目線で読めて良かった❗️ GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用 エ
Azure Portal から GitHub リポジトリを指定して Static Web Apps を作成すると自動的にワークフローが作成されますが、作成されたワークフローは Deployment Token を使うようになっています。 この Deployment Token を使う方法は非常にシンプルで扱いやすく、立ち位置としては App Service の Publish Profile と同じもので単一 SWA へのデプロイのみ可能なものです。作成されたワークフローでは公式の GitHub Action を使うため、ビルド含めすべて自動でやってくれるのでお手軽です。 シンプルに 1 つの SWA へのデプロイであればそこまで困らないのですが、モノリポで複数の SWA へのデプロイを行う場合には Deployment Token の管理が煩雑になるため、App Service や Az
チューリング完全とは、ざっくり説明すると、一部を除くほとんど全ての計算が可能な能力を意味します。言い換えると、ほとんど全ての計算問題を解く能力を意味します。(あとでもう少し詳しく説明します。)プログラミング言語は一般にチューリング完全であり、例えば TypeScript や Python はチューリング完全です。プログラミング言語以外にも、TypeScript の型システムやスーパーマリオメーカー、マジック・ザ・ギャザリングもまたチューリング完全であることが知られています[1][2][3]。直近では find と mkdir だけでチューリング完全になると報告されていましたね[4]。 逆にチューリング完全でない例としては正規表現[5]があります。チューリング完全ならば正規表現で解ける問題を全て解けますが、その逆は不可能です。例えば回文の判定は正規表現だと無理です。このように、数ある計算能力
Github Actionsとは リポジトリ内で処理を自動化してくれる機能になります。 CI/CDに使うことが多いですが、使い方次第では無限大の可能性があります。 また、自分自身で作るだけでなく世界中のエンジニアが公開しているGithub Actionsを使用して自分のプロジェクトで自動実行することも可能です。 エンジニアは基本面倒くさがり屋です。 だからこそGithub Actionsで徐々に自動化して楽なコーディングライフにして欲しいです。 自動化する処理 今回はあると便利な下記2つをGithub Actionsで自動化していこうと思います。 GithubActions処理状況をSlack通知 プルリク作成時にテスト 詳細な処理やコードは次で書いていきます。 実装 実装内容的には簡単ですので是非導入を考えて見てください。 今回はGithubActionsの他にactions/toolk
はじめに こんにちは、セキュリティエンジニアのJJ (yuasa)です。今回はGitHub Actionsのワークフローにおける脅威検知ツールであるtracee-actionを触り、検知ルールの書き方について見ていきます。なお、tracee-actionは2024年7月時点で本番環境での利用は想定されていない点にご注意ください。 This project is not production ready. We are experimenting with it to test and demostrate Tracee capabilities. tracee-action tracee-actionはTraceeを用いてGitHub Actionsのワークフローにおける脅威を検知します。TraceeはeBPFを用いてLinuxランタイム上でのシステムコールを検出することができるツールです
7月30日、GitLabで「What’s new in Git 2.46.0?」と題した記事が公開された。この記事では、Git 2.46.0の新機能と改良点について詳しく紹介されている。 1. reftablesフォーマットへの移行コマンド git-refs Git 2.45.0で導入されたreftablesフォーマットは、大規模リポジトリにおけるパフォーマンスや管理を改善する新しいバックエンドである。このリリースでは、既存のリポジトリをreftablesフォーマットに移行するための新しいコマンドgit-refsが導入された。以下はその使用例である。 # 新しいリポジトリを「ベア」として初期化 $ git init --bare . $ git commit --allow-empty -m "init" # 参照をファイルバックエンドで生成 $ git branch foo $ git
2024-07-24 追記: 本記事の続きで、開発組織でのソフトウェア開発の Issue や PR を自動で適切な GitHub Project に割り当てていく方法についても書きました。 https://zenn.dev/shunsuke_suzuki/articles/manage-enterprise-issue-pr-by-project タイトルの通り、自分が管理する全 OSS の Issue や Pull Request (以下 PR) を 1 つの GitHub Project に集約した話を紹介します。 自分は様々な OSS をメンテしており、様々なリポジトリで作られる GitHub Issues や PR を日々ハンドリングする必要があります。 しかしこれだけリポジトリの数が増えると一つ一つリポジトリを巡回してハンドリングしていくのは困難です。 ユーザーによって issu
はじめに さくらインターネット SRE室の久保です。 今日は「terraform (plan|apply) in GitHub Actions」というタイトルで発表させていただきます。 今日発表する内容は、画像で表すと上図のようになります。誰かがPull Requestを送ると、それをもとにGitHub Actionsを動かし、Terraformのplanやapplyを動かして、自動的にTerraform管理下にあるリソースを更新してくれる、そういう仕組みを作ったという話です。 terraform (plan|apply)を実行する際のポイント Terraformのplanとapplyを実行する際のポイントとして、まず各種秘匿情報、具体的にはAPIキーなどが必要になるので、実行結果をチーム内で共有してレビューするのが結構面倒です。何らかの方法でAPIキーを共有して使うにしても、あるいは各自
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での一般的なワークフローとして、「新しいフォークを作成する」「コミットする」「フォークを削除する」というものを考えてみます。 この時、削除したはずのフォークの中身を誰でも確認できてしまうとのこと。
こんにちは。スタディサプリのQAチームです。 今回のBlogではスタディサプリで実施している自動化テストの一部の取り組みについて紹介させていただきます。 なお、スタディサプリQAチームの特性を活かし、本記事については日英中3言語で記載します。より多くのオーディエンスに読んで頂ければ嬉しいです。 自動化する動機 まず、なぜ自動化テストを導入するのでしょうか。 1. 新規機能が追加される度に、既存機能への影響を確認するための回帰テストをしなければなりません。 2. 繰り返し同じテストを手動実行することにより、テストコストが増加します。 3. 人間が実施すると、人為的ミスによる不具合の検出漏れが発生してしまう可能性が否定できません。 そのため、品質を担保した上でより早くリリースすることを目的とし自動化を導入しました。 現在の開発およびテストフロー QAが回帰テストの自動化テストスクリプトをGit
GraphRAG: New tool for complex data discovery now on GitHub Published July 2, 2024 By Darren Edge , Senior Director Ha Trinh , Senior Data Scientist Steven Truitt , Principal Program Manager Jonathan Larson , Senior Principal Data Architect Earlier this year, we introduced GraphRAG (opens in new tab), a graph-based approach to retrieval-augmented generation (RAG) that enables question-answering ov
ワークフローの概要 このGitHub Actionsワークフローは以下の主要な機能を持っています: 新しいイシューが開かれたときに自動的に起動 イシューの内容を分析し、不適切なコンテンツをチェック 既存のイシューとの重複を検出 必要に応じてラベルを付与 ワークフローの詳細解説 トリガーとパーミッション設定 name: Issue Review on: issues: types: [opened] permissions: issues: write contents: read このセクションでは、ワークフローの名前を定義し、トリガー条件とパーミッションを設定しています。 on.issues.types: [opened]: 新しいイシューが開かれたときにワークフローが起動します。 permissions: ワークフローがイシューの読み書きと、リポジトリコンテンツの読み取りを行うための権
GitHub、ArmベースのLinux/Windowsランナーをパブリックベータで公開。x64ランナーより37%安価に GitHubは、GitHub上でソースコードのビルドやテストなどのさまざまな処理を行えるGitHubホステッドランナーとして、ArmベースのLinuxとWindowsのランナーをパブリックベータとして公開しました。 Did you know that our new Arm-hosted runners can decrease your carbon footprint? Learn more about how you can start using Arm-powered runners today! https://t.co/xa01sYA6yk — GitHub (@github) June 3, 2024 Armベースのランナーを利用することで、Armベースの
継続的にメンテナンスするのではなくて、雑な使い捨てでいいならshellscriptとjq職人芸でいけるので頑張ってしまったけれど、継続的にやるならもっと違うもので書いた方がメンテナンスしやすいと思います。 細かい部分はいくらでも改善の余地があるとは思いますが、とりあえず動いたのでヨシ・・・!? 以前も多少似たような何か作ったけど、こういうの誰か既にもっと綺麗に作ってないんですかね。 xuwei-k.hatenablog.com GitHub Actionsのログはデフォルトでは90日保存されてるはずなので、その程度の期間をなんとなく集計したいだけならば、こうやって後から集計するだけで十分ですね。 もちろん、yamlの内部の構造がすごく変わっていると集計が難しいか実質不可能になるリスクはありますが。 もっとしっかり計測したいならば、buildした時点で専用の場所に綺麗に記録して、他のもっとリ
5月31日、GitLabが「A beginner's guide to the Git reftable format」と題した記事を公開した。この記事では、Gitの新しいリファレンス形式である「reftable」について詳しく紹介されている。 Gitのreftable形式について Gitのリファレンスストレージは、Git 2.45.0のリリースで「reftable」という新しい形式をサポートするようになった。これは従来の「ファイル」形式に代わるものであり、いくつかの重要な改善点を提供する。以下に、reftable形式の特徴と利点について詳しく解説する。 1. 高速で効率的なリファレンス検索 reftable形式は、単一のリファレンスの検索やリファレンス範囲の反復処理を可能な限り効率的かつ迅速に行うことを目指して設計されている。これにより、大規模なリポジトリにおいても高速な操作が可能になる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く