社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
エンジニア全員が Terraform を安心・安全に触れるような仕組みを整えています - VisasQ Dev Blog
はじめに こんにちは！DPE（Developer Productivity Engineering）チームの高畑です。 ちょっと前に iPhone 15 Pro に変えてようやく USB-C ケーブルに統一できる！と思っていたら、手元にある Magic Trackpad が Lightning ケーブルでしょんぼりしました。 さて今回は、ビザスクのインフラ周りで利用している Terraform をエンジニア全員が安心・安全に利用できる仕組みづくりを行なっている話をしていきます！ これまで ビザスクではインフラの構築・運用に Terraform を利用しており、依頼ベースで DPE のメンバーが Terraform の修正を行なってレビュー＆リリースをしていました。 開発メンバーから Terraform の PR をあげてもらうこともありますが、plan / apply の権限を持っていない
最初に作ったのがCIAnalyzerです。なるべくツール自体の運用の手間がかからないように常駐サーバー無し、データの保存先と可視化はマネージドサービスを使う前提で設計しました。具体的にはデータの保存先をBigQueryとすることによって自前でDBを管理する必要をなくし、webhookを受けるのではなくcronで定期的にAPIを叩くことで常駐サーバーを不要にし、データの可視化はBigQueryと簡単に連携できてマネージドサービスであるLooker Studioを使用する前提としました。 CIAnalyzerのアーキテクチャ CIAnalyzerを作ったきっかけはAzure Pipelineの分析機能に感銘を受けたことで、それと同等の分析を当時自分が業務とプライベートで使用していたJenkins, CircleCI, Bitrise, GitHub Actionsでも可能にしたいと思って開発を
GitHub Actionsを使いこなせ！/Get Started GitHub Actions
OCHaCafe Season7 #3の資料です．
ソースコードのハッシュ値を利用したCIの高速化 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、kintoneチームの川向です。 ソースコードハッシュ値計算ツールであるsverを導入してCIの高速化を行ったので、その紹介をさせてください。 この仕組みにより、通常は1時間かかるCIの実行時間が最善のケースでは20分程度に短縮可能になりました。 導入前の課題 解決方法の検討 sverを使ったテストのスキップによるCI高速化 kintoneでのsverの利用方法 sver設定ファイルの書き方 キャシュの保存先(GitHub Actions Cache、Amazon S3) sverを使ったジョブの書き方 sver情報生成ジョブ: ハッシュ生成とキャッシュの存在確認 ビルドジョブ: 依存ファイル以外に依存しないことの確認 テストジョブ: ジョブ成功後にキャッシュ保存 下流ジョブのifの書き方 結果 課題と今後の展開 まとめ 導入前の課題 kintoneのCIの大まかな構成は以下の
本記事では GitHub Actions で pull_request event の代わりに pull_request_target を用い、 workflow の改竄を防いでより安全に CI を実行する方法について紹介します。 まずは前置きとして背景や解決したいセキュリティ的な課題について説明した後、 pull_request_target を用いた安全な CI の実行について紹介します。 本記事では OSS 開発とは違い業務で private repository を用いて複数人で開発を行うことを前提にします。 長いので要約 GitHub Actions で Workflow の改竄を防ぎたい GitHub の branch protection rule や codeowner, OIDC だけでは不十分なケースもある pull_request event の代わりに pull_r
GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 - Classi開発者ブログ
GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 こんにちは @lacolaco です。最近は、先日プレスリリースが出された「学習トレーニング」機能を裏で支えているコンテンツ管理システム（以下内部CMS）の開発に携わっています。 corp.classi.jp この記事では、内部CMSのフロントエンド（Angular アプリケーション）のリリースフローを自動化している仕組みを紹介します。現在のリリースフローの全体像は次の図のようになっています。この中にある Release Please というのが、今回特に紹介したいツールです。いくつか日本語でのブログ記事などもあるので特にマイナーというわけではないと思いますが、多くの場合はライブラリのリリースに使われています。一方、アプリケーションのリリースで使っているケースはあまり発信されてないよう
Renovateを使ってフロントエンドのバージョンアップを改善した話 | PR TIMES 開発者ブログ
こんにちは、フロントエンドエンジニアの小張です。Renovateを使ってフロントエンドのパッケージやライブラリのバージョンアップを改善したことについて紹介します。 PR TIMESではReactに関するコードを、monorepoとしてprtimes-frontendという1つのリポジトリで管理しています。 このリポジトリは作成されてから2年ほどしか経っておらず、使っているライブラリも比較的新しいため、今までバージョンアップの仕組みを特に整備していませんでした。 ただフロントエンドのライブラリはバージョンアップの頻度が多く、異なるライブラリ間でバージョンの依存関係があることもあり、将来のことを考えればライブラリのバージョンを更新する仕組みを作ることはほぼ必須でした。 また、monorepoであるためライブラリのバージョンを大きくあげようとした際の対応コストも大きく、最新との差が小さいうちに細
概要 この記事は 一休.com Advent Calendar 2023 16日目の記事です。 RESZAIKO開発チームの松村です。 一休では各サービス毎に、開発中のサービスの動作を社内で確認できる環境があります。 それぞれmain(master)ブランチと自動的に同期している環境と、特定のブランチを指定して利用できる環境の2種類があります。 今回、RESZAIKOの新規サービス(予約画面)に対してブランチを指定してデプロイできる環境を作成したので、その方針と反省点と今後について記述していきます。 現在運用中の予約画面 開発環境を作る理由 一休では長らく、EKS上に複数の環境を用意して、ブランチを指定すると開発環境にデプロイするシステムが利用されてきました。 一般的にこのような環境を構築するのは以下のような理由が挙げられます。 動作確認 マイクロサービスで、異なるブランチ同士の組み合わせ
実行時間ベースでテストを分割するGitHub Action
GitHub Actionsでテストファイルを複数ノードに適切に分割するためのカスタムアクション、r7kamura/split-tests-by-timingsを作った。 CircleCIに同様の仕組みがあり、今回はこれのGitHub Actions版が欲しかった。 既存ツールとして、Go製のleonid-shevtsov/split_testsというCLIツールがあり、これを利用するchaosaffe/split-testsというカスタムアクションがある。 このカスタムアクションでも不足は無かったが、幾つかの理由で今回自作するに至った。 しばらく使いそうなので、保守性を上げるためにも、不要な機能を取り除いて必要最低限の機能にしたかった GitHub Actionsは仕様変更が多いため、自分で保守できるようにしたかった 今回、内部実装としてRust製のmtsmfm/split-testとい
name: Container deploy on: release: types: [published] concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true env: REGISTRY: ghcr.io IMAGE_NAME: pinto0309/test jobs: docker-deploy: runs-on: ubuntu-22.04 permissions: contents: read packages: write steps: - name: Git checkout uses: actions/checkout@v3 - name: Enable buildx uses: docker/setup-buildx-action@v2 - name: Ch
GitHub Actions から AWS へのアクセスに利用している OpenID Connect ID Provider の thumbprint について調査した - ROUTE06 Tech Blog
ROUTE06 でエンジニアリングマネージャ兼ソフトウェアエンジニアとして働いております海老沢 (@satococoa) と申します。 先日発生した GitHub Actions と AWS の OpenID Connect 連携におけるトラブルに関して調査を行い、対応方針を策定した件を共有したいと思います。 [2023/07/10 追記] Thumbprint を明示的にユーザ側で設定しなくて良いように、AWS 側で対応されたそうです。 github.com 当面 Terraform のモジュール的には必須入力のままですが、任意の文字列で良いそうです。 （いずれ入力も不要になるのかと思います。） https://github.com/aws-actions/configure-aws-credentials/issues/357#issuecomment-1626357333 The A
mirage-ecsで各メンバー専用開発サーバーを実現！まちのコインの運用事例を紹介します - KAYAC engineers' blog
SREチームの長田です。 突然ですが、 mirage-ecs というツールをご存知でしょうか？ 今回はこのツールをまちのコインの開発チームでの使用例をもとに紹介します。 coin.machino.co mirage-ecs を使うと動作確認用のサーバー環境を、サーバーサイドのエンジニアでなくとも自由にいくつでも立ち上げることができるようになります。 「環境」は AWS のECSクラスタ上で起動し、専用のURLが割り当てられ、 認証*1を通過すればどこからでもアクセスできます。 これにより 「クライアントアプリとつなぎ込んで動作確認したいけど、開発環境が空いてないから確認できない」 や、 「プロダクトオーナーに新機能を確認してもらいたいけど、開発環境が空いてないから(以下略)」 といった問題が解消し、 開発と動作確認のサイクルをスピーディーに回すことができるようになります。 mirage-e
GitHub Actions から AWS や GCP などのクラウドリソースを操作するときは、 OIDC を使用することが主流だと思いますが、手順に沿って設定はできるもの仕組みがよく分かっていない方も多いと思います。 この問題は厄介で、様々な"分からない"が絡まりあって生まれている問題だと思います。 例えば、 どんな仕組み・流れでAWS・GCPを操作できるようになっているのか分からない（私） そもそもなぜOIDCを設定すると嬉しいのか分からない（私） 色々な設定をしたけど何をしているのか分からない（私） などが挙げられると思います。 これらを解消し、OIDCを利用したGitHub ActionsとGCPの連携の流れ・仕組みを探求するのがこの記事の目的です。 ※Google CloudのことはGCPと書きます。 ※記事で触れないこと GitHub Actions - Google Clou
以前にセルフホストランナーの知られざる機能であるジョブの前後に任意のスクリプトを実行できるhookを紹介しました。 今回はセルフホストランナーの知られざる機能の紹介第二弾としてactions/runner-container-hooksを紹介します。 runner-container-hooksは2023年現在では比較的新しい機能で、自分もいつ頃に知ったのかは覚えていないのですが、actions/runnerのリポジトリには2022年の4-5月頃に追加されていたようです。実装のpull-reqから少し遅れて5月には設計ドキュメントと言えるADRのpull-reqが出されています。 このADRを見たところ自分がセルフホストランナーを運用する上で今まではどうしても不可能であったコンテナの中で起動したセルフホストランナーの中でコンテナ型のactionなどが実行できないという制約を突破できることが
GitHub ActionsでEnvironmentsを使わずにManual approvalを実装する - KAYAC engineers' blog
SREの今です。 CircleCIやGitHub Actions等のCI/CDツールでデプロイの自動化に取り組む際に、意図しない本番反映の防止策として承認アクション(Manual approval)を挟んでおくことがあります。 GitHub Actionsでは、Environmentsを利用することでワークフローの実行前にレビューを必須化することが出来ます1。しかし、この機能をプライベートリポジトリで利用するにはリポジトリの所有者がGitHub Enterpriseを契約している必要があります2。 業務の都合上、Environmentsを利用できないリポジトリでManual approvalを利用したい機会があり、ワークフロー実行履歴を利用したManual approvalを実装したのでご紹介します。 本記事はSRE連載の12月号 + 面白法人グループ Advent Calendar 20
Github Actionsでget-diff-actionを用いてDocker Build時間を削減する
こんにちは！アルダグラムの開発ユニット長の田中です！ 突然ですが、少しでもCIの実行時間を削減したいと思いませんか？ 今回は、GitHub Actionsとget-diff-actionを活用してDockerビルド時間を削減する方法についてご紹介します。 TL;DR get-diff-actionを使用してライブラリの変更差分を検知します。 変更差分がない場合はライブラリインストール済みのDockerイメージを使用してBuild時間を短縮します。 サンプルコード 具体的な例として、Railsアプリケーションを使用します。 on: pull_request: types: [ closed ] branches: - 'develop' name: Deploy to Amazon ECS jobs: ecr-push: name: Deploy runs-on: ubuntu-latest
FindyでEMをしている栁沢（@nipe0324a）です。 今回は、FindyのとあるRailsのCIのテスト実行時間を10分から5分に高速化した話をご紹介します。 「CIのテスト実行時間が遅い...」 「CIの実行時間を短くしたい!!」 と感じている方はぜひご覧くださいませ。 Findyでは2024年2月現在、1人あたり1日4プルリクを平均で作っています。静的解析や自動テストなどを即時に行うCI環境がないとスピード感のある開発ができなくなるため、CIを高速で回しタスクを完了させる必要があります。機能も増え、テストケースも拡充したことでCIの高速化が求められるようになりました。 また、個人的には、CIは遅くても10分、理想は5分以内で終わるのを1つの目安にしています。これぐらいのスピード感でCIが完了すると、「プルリク作ってレビュー依頼する」、「レビューコメントもらって対応する」といった
GitHub、Apple M1チップでGitHub Actionsの処理を実行する「M1 macOSランナー」提供開始、パブリックベータとして
GitHub、Apple M1チップでGitHub Actionsの処理を実行する「M1 macOSランナー」提供開始、パブリックベータとして GitHubは、コードのビルドやテスト環境などで使えるGitHub-hosted runnerとして、Apple M1チップによる「M1 macOSランナー」の提供をパブリックベータとして開始すると発表しました。 Speed up your GitHub Actions jobs on macOS with all new, faster Apple silicon powered M1 macOS larger runner for arm64. https://t.co/zUlsVaVAJZ — GitHub (@github) October 2, 2023 GitHubは、GitHub Actionsによるワークフローの一部として、コードの
I love GitHub Actions: I’ve been a daily user of it since 2019 for both professional and hobbyist projects, and have found it invaluable to both my overall productivity and peace of mind. I’m just old enough to have used Travis CI et al. professionally before moving to GitHub Actions, and I do not look back with joy1. By and large, GitHub Actions continues to delight me and grow new features that
毎月や半年に一回といったように、リリースする時期(間隔)を決めて更新するタイプのパッケージがあります。 具体的には、次のtextlintのプリセットルールは1月と7月という形で半年に一回リリースしています。 textlint-ja/textlint-rule-preset-japanese: textlint rule preset for Japanese. textlint-ja/textlint-rule-preset-ja-technical-writing: 技術文書向けのtextlintルールプリセット なぜ、このようにリリースする時期を決めているかというと、これらのパッケージは他のパッケージに依存していて、他のパッケージの更新がそのままメジャーアップデートになりやすい性質があるためです。 そのため、依存を更新してリリースすると、頻繁にメジャーアップデートしないといけなくなりま
GitHub - ysk8hori/delta-typescript-graph-action: This GitHub Action uses Mermaid to visualize in a diagram the files that were changed in a Pull Request and their related dependency files.
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
こんにちは！学習動画・Webテストの開発を行っています エンジニアの daichi (id:kudoa) です。 この記事では、最近チームで導入したライブラリアップデートを自動化した仕組みとその経緯について紹介します。 なぜ自動化しようと思ったか サービスを開発するだけではなく、日々の運用も必要です。 その運用業務の1つとして、ライブラリのアップデートがあります。 これはサービスを運用する上では大切なことではありますが、日々ライブラリアップデートのPRをさばき続けるのも大変です。 その時間をできるだけ減らし、その分空いた時間をユーザーへの価値提供や将来の投資に充てるために、今回の自動化の仕組みを作成しました。 この辺りの話は以前勉強会でLTしたことがありますので、興味があればご覧ください。 作ったもの 前置きは長くなりましたが、凝ったものを作ったわけではありません。 作成したものはライブラ
GitHub Actions から Google Cloud を使う際の gcloud バージョンを固定することにした - stefafafan の fa は3つです
弊チームではGitHub ActionsからGoogle Cloud Runにアプリケーションをデプロイしてプレビュー環境として利用しています。具体的な構成などについては以下の記事をご参照ください。 developer.hatenastaff.com 先日、内部で使われているGoogle CloudのCLI gcloud のバージョンが上がったことによりこの環境が正常に動かなくなって困った事例があったので、今回これを機にバージョンを固定することにしました。 gcloud のバージョンが上がってどのように壊れたのか 445.0.0 (2023-09-06) から 446.0.0 (2023-09-12) に上がった結果以下の Issue Tracker にあるような挙動の変化がありました。 https://issuetracker.google.com/issues/300221542 弊チ
GitHub - GitHubSecurityLab/actions-permissions: GitHub token permissions Monitor and Advisor actions
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/create-github-app-token: GitHub Action for creating a GitHub App Installation Access Token
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 で Xcode のインクリメンタルビルドを実現する (xcode-cache アクション) - Qiita
GitHub Actions で iOS アプリをビルドするときの Xcode のインクリメンタルビルドを有効にするためのキャッシュ設定について解説します。 CI でのビルドで Xcode のインクリメンタルビルドが使えるようになれば、毎回 CI 上でフルビルドし40分程度かかっていたプロジェクトが、差分のみのビルドでビルド時間が5分に短縮されたりすることが期待できます。 環境 この記事では、以下の環境で調査・検証した結果を記載しています。 ローカル環境 macOS Ventura 13.5.1 Xcode 14.3.1 (14E300c) APFS (Encrypted / Case Insentive) GitHub Actions 環境 macos-latest macOS Monterey 12.6.8 Xcode 14.2.0 (14C18) 結論 結論としては xcode-ca
皆さん、こんにちは！ @hoshinotsuyoshi です。今回は、私が開発した便利なツールについて紹介したいと思います。このツールは、GitHubのCODEOWNERSファイルの変更を正確に報告し、プルリクエストのレビューを効率的に進めるのに役立ちます。 背景 プロジェクトの管理では、CODEOWNERSファイルを使用して、特定のファイルやディレクトリに対する所有者（コードの保有者）を指定することがあります。 しかし、このファイルの解釈・パースは複雑怪奇で、このファイルの内容が変更された場合、具体的にどのファイルが影響を受けるのかを把握するのは簡単ではありません。 同僚のmh4gfさんの記事 GitHubのCODEOWNERSで一部サブディレクトリだけ別のオーナーを指定する も御覧ください。 サブディレクトリだけ別のオーナーを指定するときにこんな書き方をしないといけないんです。 どうで
こんにちは、セキュリティチームの@sota1235です。 10Xのセキュリティチームではプロダクトに近い領域での権限管理に関して、リスク整理と対応を日々行なっています。 今回はその取り組みの一環であるGitHub Actionsのpermissionsに関しての取り組みをご紹介します！ なぜやるのか そもそもこの取り組みを始めたWhyを軽く説明します。 10XではGitHubで日々の業務が行われており、守るべき資産の数多くがGitHub上で管理されています。 また、アプリケーションのデプロイや日々の運用などもGitHub Acitonsを利用しながら行われており、もしGitHub上で何かしらのセキュリティリスクが顕在化した時のダメージは大きいです。 例えば守るべき主な資産は以下が挙げられます。 Git管理されているソースコード 業務上のやり取りが行われるIssue、Pull Request
GitHub - azu/rss-to-twitter: GitHub Actions: RSS to Twitter
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
ProductGitHub-hosted runners: Double the power for open sourceGitHub Actions continues its industry-leading support for the OSS community by doubling the Windows/Linux machine size to 4-vCPU runners at no cost for public repositories. GitHub is thrilled to announce the completion of an upgrade to our GitHub Actions-hosted runners by offering larger more powerful machines to open source developers.
GitHub - Kesin11/actions-timeline: An Action shows timeline of a workflow in a run summary.
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
actions/cache@v4ではヒットしなかったときcache-hit=='false'にならない - ぽよメモ
cache-hitとは v4における挙動変更（？） cache-hitがfalseを返さない ワークアラウンド cache-hitとは GitHub Actionsのキャッシュ用actionであるactions/cacheは、指定したキーに完全一致するキャッシュがヒットしたかどうかのパラメータをそのstepのoutputとして保持している。 つまり以下の様にすることで、キャッシュがヒットしたかどうかを判定し、何かアクションするということが可能である。 jobs: run: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/cache@v4 id: cache with: path: ./cache-dir key: your-cache-key - if: steps.cache.output
FrankenPHP を CloudRun で動かして、1イメージだけでサーバーを実行できるのか試してみる2024-03-06 隙あらば自分語り１ 3/8 14:40-15:20 に PHPerKaigi で話します。 PHP を Docker に固めてデプロイするときに ApacheやらNginxが求められることに対して、そもそも Webサーバーとは何かという話をします。 FrankenPHPも、Dockerに固めてデプロイするときの解決策の一つとして紹介します。 see: https://fortee.jp/phperkaigi-2024/proposal/42d9e721-b3e8-4a7d-ae88-1727ccfabf9b 隙あらば自分語り２ 年パスを持っていたので小さい頃ユニバによく行っていました。 ユニバにモンスター・メーキャップ っていうフランケンシュタインが出てくるアトラ
前回書いたのがもう4年前でビビったのと、最近いろいろ進展があったのでまとめてみます。 actions/setup-java の依存キャッシュを使わない これ自分が実装した機能なのでホント申し訳ないんですけど、今なら gradle/gradle-build-action を使ったほうが良いです。 利点は公式が説明しているので読んどいてください。 github.com spotlessApplyして差分が出たらSuggest Changeする reviewdogが action-suggester という素敵なアクションを提供しています。GitHub Actionsでフォーマッタを実行して差分ができた状態でこのアクションを実行すると、GitHub Pull RequestのSuggest Change機能を使ってフォーマットを提案してくれます。 github.com フォーマット適用箇所が多い
GHES の GitHub Actions で Google Cloud との OIDC 連携がしやすくなりました
みなさん GitHub Actions の OpenID Connect (以下OIDC) 連携使っていますか？ GitHub Actions はワークフローの中で OIDC の ID トークンを発行でき，これを Google Cloud などのクラウドプロバイダの認証に用いることでサービスアカウントのクレデンシャルを発行することなくクラウドプロバイダのリソースをワークフロー内で操作できるようになります．これによりクレデンシャルのローテーションなどの管理コストが減り，よりセキュアな連携が可能になります． 詳しくは GitHub の公式ドキュメントや解説記事を見ていただけると良いと思います． 基本的に良いことづくめな OIDC 連携ですが，GitHub Enterprise Server (オンプレ版 GitHub．以下GHES) では OIDC 連携が難しいケースがあります．OIDC 連携
GitHub - AlexSim93/pull-request-analytics-action: Generates detailed PR analytics reports within GitHub, focusing on review efficiency and team performance.
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
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Actionsのワークフローを可視化するactions-timelineを作った
pull_request_target で GitHub Actions の改竄を防ぐ
Cloud Runで開発用環境を沢山作る - 一休.com Developers Blog
GitHub Actions のストレージ空き容量を限界まで拡張する
GitHub ActionsとGoogle CloudのOIDCの仕組みを理解する
コンテナのセルフホストランナーの中でコンテナを使えるようにするrunner-container-hooks
RailsのCIのテスト実行時間を 10分から5分に高速化した話 - Findy Tech Blog
GitHub Actions could be so much better
時期を決めて定期的に更新するnpmパッケージをChangesetsで管理する
ライブラリのアップデートを自動化した仕組みの紹介 - Classi開発者ブログ
GitHub ActionsでCODEOWNERSファイルの変更を詳細に報告するツール
GitHub Actionsのpermissionを粛々と整理した話 - 10X Product Blog
GitHub-hosted runners: Double the power for open source
FrankenPHP を CloudRun で動かして、1イメージだけでサーバーを実行できるのか試してみる
Gradle用のGitHub Actions勘どころ（2023年夏） - Kengo's blog