Cloudflare Containers 上に GitHub Actions のエフェメラル self-hosted runner を webhook 駆動で立てて、実測とともに GitHub-hosted runner との料金比較をしてみた。
こんにちは、hatsu です。 先日、GitHub Actions で同じ job の中にある複数のステップを並列に実行できる parallel / background が 2026-06-25 に GA になりましたね。 これまで job の並列化はできましたが、step の並列化はできませんでした。 今回この parallel を実際のワークフローに入れてみて、ちゃんと速くなった例と、そこまででもなかった例があったので、そのあたりを書いていきます。 TL;DR 2026-06-25 に steps 並列(parallel: / background: + wait:)が GA。同じ job、同じランナーの中で独立したステップを並列化できる 効き方は大きく2種類あった 直列だった処理を並列にして、終わるまでの時間を縮める(本番デプロイが8分→3分) 別ランナーに分かれていた job を
2026年6月23日に、GMO Flatt Security主催の「OSS開発者は今何をするべきか?ソフトウェアサプライチェーン侵害対策を考える」で「Hardening npm Publishing」というタイトルで、npmパッケージの公開フローをどう守るかについて話しました。 スライド: Hardening npm Publishing ローカルのトークン管理やnpm Trusted Publishingについては、以前の記事で書きました。 1Passwordを使って、ローカルにファイル(~/.configや.env)として置かれてる生のパスワードなどを削除した | Web Scratch パスワード管理/MFA管理の戦略 | Web Scratch npm Trusted PublishingでOIDCを使ってトークンレスでCIからnpmパッケージを公開する この記事ではそれらを前提に
newmo では依存パッケージの更新に Renovate を使っています。これまでは Mend が提供するクラウド版(Mend-hosted の GitHub App)を利用していました。しかし Kernel out-of-memory エラーで Renovate がまともに動かなくなりました。 この記事では、なぜ動かなくなったのか、そしてクラウド版から GitHub Actions 上で動かす Self-host 版へどう移行したのかを紹介します。 過去に書いた Renovate と pnpm catalog で依存を管理する話 の続編にあたる内容です。 先に結論 クラウド版 Renovate がメモリ制約(3GB)で Kernel out-of-memory を起こし、PR を作れなくなった メモリ・実行時間・環境変数の制約を回避するため、GitHub Actions 上で動かす Se
GitHubのAuto Mergeをひとつの必須チェックに集約するためのGitHub Action automerge-gate を作ったので紹介します。 GitHub: pkgdeps/automerge-gate 背景: GitHub Auto Mergeは集約するアクションなしだと使いにくい 前提として、GitHubのAuto Mergeを使うには、必須チェック未達成のPRをマージできない状態にするBranch protection ruleやRulesetの設定が必要です。 これらの保護機能でPRがブロックされる状態を作ったうえで、すべての必須チェックが成功した時点でAuto Mergeが発火する、という仕組みになっています。 逆に言うと、Auto Mergeを使うには何かしらのステータスチェックを必ず必須に入れる必要があります。 そして、Branch protection rul
!a.isFolder&&!b.isFolder||a.isFolder&&b.isFolder?a.displayName.localeCompare(b.displayName,void 0,{numeric:!0,sensitivity:\"base\"}):!a.isFolder&&b.isFolder?1:-1","filterFn":"node=>node.slug.startsWith(\"publish\")||node.slug.startsWith(\"articles\")","mapFn":"node=>node"}">エクスプローラー Quartzで保管庫の一部を公開しているが、その保管庫をObsidian Syncから取り出すことができるようになった。 GitHub - atty303/obsidian-quartz: Publish my Obsidian v
Pull requests are the beating heart of GitHub. As engineers, this is where we spend a good portion of our time. And at GitHub’s scale—where pull requests can range from tiny one-line fixes to changes spanning thousands of files and millions of lines—the pull request review experience has to stay fast and responsive. We recently shipped the new React-based experience for the Files changed tab (now
A week-long automated attack campaign targeted CI/CD pipelines across major open source repositories, achieving remote code execution in at least 4 out of 7 targets. The attacker, an autonomous bot called hackerbot-claw, used 5 different exploitation techniques and successfully exfiltrated a GitHub token with write permissions from one of the most popular repositories on GitHub. We're entering an
TLDR: We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach. We are continuing to reduce hosted-runners prices by up to 39% on January 1, 2026. We’ve read your posts and heard your feedback. We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach. We are continuing to reduc
newmoでは、pnpm workspaceで管理している複数のアプリケーションやライブラリに対してESLintを実行しています。 プロジェクトの成長とともにLint対象のファイル数が増加し、CI実行時間とメモリ使用量が増加していました。GitHub Actionsのmatrixオプションを使用した動的なShardingを実装し、これらの問題に対応しました。 newmoフロントエンドの開発原則 newmoのフロントエンド開発では、次の原則を重視しています。 1つ目は、「同じ目的を達成するための手段を統一する」という原則です。同じ目的に対する複数の手段が混在するよりも、統一した手段を使うことで学習コストや保守コストを削減できます。例えば、npmパッケージのバージョン管理では、One Version Ruleに基づき、同じ目的を持つライブラリは1つに絞っています。これは「同じコードを書かない」
2025年8月15日にGitHubからGitHub Actions周りの新機能として "SHA pinning enforcement" 機能がリリースされました。今年の3月にGitHub Actionsでのサプライチェーン攻撃があったことは記憶に新しいと思います。この新機能はこの種のサプライチェーン攻撃のリスクを低下させるためのものだと考えています。 まだリリース後間もないので不安定な部分もありますが、セキュリティ向上を目的にFinatextではこの機能の有効化に取り組みました。Finatextでのソフトウェア開発にはある程度の規模があるため、単に機能を有効にするのではなくプラットフォームとしての仕組みを整備しました。その過程を紹介します。 機能の概要 SHA pinning enforcementに関するまとめ記事を参考にしましたが、検証した結果一部さらに詳細な挙動が分かりました。 こ
Template URLs for fine-grained PATs and updated permissions UI @cole-hartman and @dorisbwang joined the GitHub Apps team for the summer with a focus on improving the developer experience around fine-grained PAT creation. They worked with our design and product team to ship two enhancements based on community feedback: A new UX for picking permissions that more closely resembles the permission pick
GitHub Actions Supply Chain Attack: A Targeted Attack on Coinbase Expanded to the Widespread tj-actions/changed-files Incident: Threat Assessment (Updated 4/2) Executive Summary Update April 2: Recent investigations have revealed preliminary steps in the tj-actions and reviewdog compromise that were not known until now. We have pieced together the stages that led to the original compromise, provid
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
[追記 2024/8/1] 修正のPRがマージされました [追記 2024/10/9] 修正がリバートされました cache-hitとは v4における挙動変更(?) cache-hitがfalseを返さない ワークアラウンド [追記 2024/8/1] 修正のPRがマージされました まだリリースされていませんが次のリリースに含まれるでしょう。 github.com [追記 2024/10/9] 修正がリバートされました v4.1.0で修正された本変更だが、空文字になるという挙動に依存していた人が予想よりも多く、元の挙動に戻すという決定がされた。 github.com v4.1.1ではこの記事の通り cache-hit=='false' にならず、空文字が返る。 詳しくは以下のコメントを参照して欲しいが、そもそも cache-hit というパラメータの表すものが難しく、将来的にはパラメータの
TLDR: This post outlines how we were able to replace our usage of long-lived GitHub Personal Access Tokens (PATs) with short-lived credentials across several GitHub organizations managed by Chainguard. To eliminate our need for these long-lived credentials, we created Octo STS to act as a “Security Token Service” (STS) for GitHub credentials. One of our mantras at Chainguard is: treat your build
2024年2月21日ごろから、"Github Jobs"を名乗るGitHubの開発者ポジションをオファーするスパム攻撃が発生しています。 仕組みとしては、GitHubのIssueやPRでmentionをするとメールの通知が届くのを利用して、コメントでスパムメッセージを送りつけるものです。 以前からこのスパムは存在していましたが、今回おきた問題はGitHub OAuth Appを用意して、スパムコメントで24時間以内にここから申請してくださいという感じの誘導して、OAuthアプリの認証を行わせる攻撃が含まれていました。 このスパムOAuthアプリは、GitHubのprivateリポジトリの読み取りやコメントの読み書きなどの権限も持っていたため、このスパムアプリを認可してしまうと、その人のアカウントでさらにスパムコメントが増えるという問題が起きていました。 詳細は、次のGitHub Discu
同僚に「GitHubのMerge Queueってあんまり知らないんだけど、どう思う?」って聞かれて「あー。僕もあれよく分かってないんだよね」って返事をして、ちょうどいい機会なので見てみた 見てみた感想としては、いくつか気をつけておきたい点があるけど、チームの開発の進め方にうまくはまれば便利な機能だな、という感じ(なんでもそうか・・・) Merge Queueって? 2023年の7月にGAになったGitHubの機能 プルリクエストをマージするときに「マージ先のブランチ(ベースブランチ)の最新の変更を取り込んでからChecks(つまりCI)を実行して、それが成功したらマージしといて!」ってお願いできる便利機能。名前のとおりQueueになっているので複数のプルリクエストからenqueueできて前から順番に処理してくれる そうは言われても最初に説明を見た僕は「???」状態だった。「なんでこんな機能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く