どんな人向けの記事？ レビューによって心理的なダメージを受けやすい方 非エンジニアだが、エンジニアチームがどんな機能を作っているか知りたい方 業務が溜まっていて、レビューに割く時間を捻出するのに苦労している方 コピペできるコードも公開します 初回レビューをAIに任せると、いろんなロールの人の役に立つ レビューは得意ですか？ 優秀なエンジニアしかいないチームであれば、PRは1トピックに絞って小さく明確なコミットによって作成され、適切な要約とともに提供されることでしょう。 しかし、実際にはいろいろな制約から、PRが想定よりずっと大きくなってしまったり、関連トピックと異なるコードが混じってしまうこともあります。 実際のところ、大きなPRを適切にレビューするのは難しいことです。また、自分が詳しくない領域のレビューを行わなければいけない機会もあります。 今回の記事は、レビューを作成してくれるAI C
1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo
Github Actions チートシート
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 push時に実行 // feature/aaaで動く。 feature/aaa/bbbでは動かない on: push: branches: - feature/* // feature/aaa, feature/aaa/bbbで動く on: push: branches: - feature/** // なにかしらのtagがpushされたときに実行、branchのpushは無視 on: push: tags: [ '**' ] branches-ignore: [ '**' ] // 指定したpathの変更だけでは実行しない on: push: branches: - main paths-ignore: - '*.md' - 'docs/**' on: workflow_dispatch: inputs
社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
CTO室SREの @sinsoku です。 社内のGitHub ActionsのYAMLが複雑になってきたので、私が参考にしてる情報や注意点、イディオムなどをまとめておきます。 頻繁に参照するページ 新しい機能の説明が日本語ページに反映されていないため、基本的に英語ページを読むことを推奨。 ワークフロー構文 YAMLの基本構文の確認 コンテキストおよび式の構文 github オブジェクトの情報、関数の確認 ワークフローをトリガーするイベント 各イベントの GITHUB_SHA と GITHUB_REF が記載されている About GitHub-hosted runners インストールされているSoftwareのバージョンなどが記載されている GitHub REST API APIを使うときに参照する よく使うaction actions/checkout イベントによってはデフォルトブ
対象読者判定フロー 以下の質問にはいかいいえで答えてください。 Q1: GitHub を使用していますか？ はいの方→次の質問に進んでください。 いいえの方→対象外です。すみません。 Q2: ソースコードなどの変更は全てプルリクエストで行って（＝master/main 直コミットはしていない（多少ならOK））いますか？ はいの方→次の質問に進んでください。 いいえの方→まずはプルリクエストベースの開発に切り替えてみてはいかがでしょう？ その後で続きを読んでください。 Q3: リリースノートをちゃんと書いていますか？ はいの方→基本的に対象外です。継続して書いていって下さい。楽をしたいと思ってる場合は続きを読んでください。 いいえの方→あなたは対象読者です！ この記事を読んで、お手軽自動生成でも良いのでリリースノートを作成しましょう！ はじめに 公開しているソフトウエアにバージョン番号を付け
本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった！」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人 GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人 本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。 GitHub Actionsの設計指針 GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期
この記事について GitHub Actionsには、以下3つの実行単位が存在します。 Workflow Job Step パイプラインを組む中で出てくる複数個の処理を、1つの実行単位でまとめてしまうか、それとも分割するのかというのは悩むポイントかと思います。 一つのstepのrunフィールドにコマンドを詰め込む？それともstepを分けた方がいい？ 一つのJobの中のstepとして記述した方がいい？それとも別のJobに定義した方がいい？ 一つのWorkflowの中にJobをたくさん定義する？それともWorkflowを別にする？ この記事では、Workflow・Job・Stepそれぞれの性質を踏まえた上で、ベストな処理単位の選び方を考察します。 使用する環境・バージョン GitHub Actions: 2022/5/15時点での機能をもとに考察 読者に要求する前提知識 GitHub Actio
こんにちは、Software Engineer in Qualityチーム(通称SEQチーム)の @teyamagu です。 私たちのチームは普段自動/手動テストの基盤開発や開発フィードバックサイクルの高速化に向けた開発をおこなっています。 その一環で、先日、社内でfreeeの自動テストシステム全体像を共有したのですが、この辺りのことを社外の友人達と話したところ、自動テストの具体的な構成や普段の運用など事例が少なく、どんなことをやっているのかイメージしにくいとの話を伺ったので、社内向け原稿をちょっと手直しして、おすそ分けと言うことで、ここで紹介します。 特に変わったことをおこなっているわけではありませんが、自動テストの関係性の理解に参考になれば幸いです。 基本的な考え方 自動テストが既存のデプロイ・リリースのブロッカーではなく、開発のフィードバックを加速させるために、自動テストそのものが高
業務で使えるかもしれない…！？GitHub Actions の Tips 集 / CI/CD Test Night #7
Event https://testnight.connpass.com/event/311263/ Archive https://youtu.be/96KUNLiMe6w?t=327
GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される - shmokmt's blog
GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される 大事なことなので、見出しでも同じことを書いてしまいました。 何を言っているんだという感じですが、とにかくそういうことらしいです。 厳密には最後にワークフローにコミットしたユーザーが組織から削除されると、無効になるようです。 GitHub Actionsの定期実行でPR作成を自動化*1している会社もそれなりにあるかと思うのですが、その場合はそれらが全部停まります。 さらに、1度無効化されてしまった場合はcron式を変更しないといけないというのも罠ポイントですね。 最後にワークフローの Cron スケジュールにコミットしたユーザーが組織から削除されると、スケジュールされたワークフローは無効になります。 リポジトリへの write アクセス許可を持つユーザーが Cron スケ
はじめに スタートアップ等において新しいプロダクトを始める時は、負債が無い代わりに何もありません。 そういった時に、ソフトウェアの品質を担保するための CI のセットアップが、初期から重要になってきます。 GitHub を使用している場合は、GitHub Actions を使用されることが殆どだと思うので、そちらを前提に進めていきたいと思います。 1. rhysd/actionlint 様々なエンジニアが action を追加したり、編集したりするようになった時、全員が正しい書き方で書いていくことは難しいです。 また、それを 1 人の GitHub Actions Expert がレビューしていくのは大変で、属人化してしまっているので、避ける方が望ましいです。 以下をコピペすれば、使用できます。 name: Actionlint on: push: branches: [ main ] p
ついに最強のCI/CDが完成した 〜巨大リポジトリで各チームが独立して・安全に・高速にリリースする〜 - ZOZO TECH BLOG
こんにちは。SRE部の巣立（@ksudate）です。 我々のチームでは、AWS上で多数のマイクロサービスを構築・運用しています。マイクロサービスが増えるにつれて、CI/CDの長期化やリリース手法の分散など様々な課題に直面しました。 本記事では、それらの課題をどのように解決したのかを紹介します。 目次 目次 はじめに CI/CDのこれまで Release PRによるリリース CI/CD実行時間の長期化 マイクロサービスごとのリリースが難しい リリーサーの制限ができない ドメイン単位の並行リリース リリース手法が分散する ブランチ間の同期が必要 パイプラインの増加 CI/CD実行時間の長期化 リリーサーを制限できない CI/CDの刷新 高速かつシンプルなCIパイプライン 変更差分を利用したCIパイプラインの実行 承認機能付きのCDパイプライン GitHub Environmentsによるリリー
GitHub Actions のワークフローをチェックする actionlint をつくった - はやくプログラムになりたい
GitHub Actions のワークフローを静的にチェックする actionlint というコマンドラインツールを最近つくっていて，概ね欲しい機能が揃って実装も安定してきたので紹介します． github.com なぜワークフローファイルの lint をすべきなのか GitHub Actions が正式リリースされてからだいぶ経ち，GitHub 上での CI は GitHub Actions が第一候補となってきているように感じます．僕も新規にリポジトリを作成して CI をセットアップする場合はほぼ GitHub Actions を使っています． ですが，GitHub Actions には下記のような問題があり，actionlint でそれらを解決・緩和したいというのが理由です． ワークフローを実装する時は，GitHub に push して CI が実行されるのを待って結果を確認するという
Claude CodeとGitHub Issueを使った全自動開発について注意事項 #現在多数の方に閲覧されていますが、こちらの記事はまだ試験段階であり、改善の余地はたくさんあると考えています。 使用する際は十分ご注意ください。 このコードを使用したことで発生する不利益については、筆者は一切責任を負いません。 ご了承ください。 準備 #wikiは使用しないdocsディレクトリで管理するREADME.mdにプロジェクト概要を書くGitHub Issueのtemplateを作成する.github/ISSUE_TEMPLATE/配下先にIssueを作成しておくdocs/db-schema.md から docs/er.md を作成ログイン画面作成User一覧作成などなどghコマンドをインストールする出先からの実行専用スクリプト #Priority & issue番号で並び替えして最初のissueを
最初に作ったのがCIAnalyzerです。なるべくツール自体の運用の手間がかからないように常駐サーバー無し、データの保存先と可視化はマネージドサービスを使う前提で設計しました。具体的にはデータの保存先をBigQueryとすることによって自前でDBを管理する必要をなくし、webhookを受けるのではなくcronで定期的にAPIを叩くことで常駐サーバーを不要にし、データの可視化はBigQueryと簡単に連携できてマネージドサービスであるLooker Studioを使用する前提としました。 CIAnalyzerのアーキテクチャ CIAnalyzerを作ったきっかけはAzure Pipelineの分析機能に感銘を受けたことで、それと同等の分析を当時自分が業務とプライベートで使用していたJenkins, CircleCI, Bitrise, GitHub Actionsでも可能にしたいと思って開発を
CI/CD Conference 2023 #CICD2023 https://event.cloudnativedays.jp/cicd2023/talks/1766
GitHub Actionsを試すときに、いちいちコミットしないといけないのがめんどくさいので、 ローカルで確認できればな〜と思い、色々調べたときの備忘録。 Dockerを立ち上げてローカルで実行できるのがあった...(*´ω｀*) ・nektos/act: Run your GitHub Actions locally 🚀 使ったサンプルはこれ(*´ω｀*) # ./github/workflows/build.yml # ./github/workflows/test.yml name: Act Sample on: release: types: [created] jobs: build: runs-on: ubuntu-latest steps: - run: | echo "MY_ENV_VAR = ${{ env.MY_ENV_VAR }}" echo "MY_2ND_EN
『GitHub CI/CD実践ガイド』でGitHub ActionsとCI/CDを体系的に学ぼう - 憂鬱な世界にネコパンチ！
『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本？ GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/
Amazon ECSで動かすRailsアプリのDockerfileとGitHub Actionsのビルド設定 - メドピア開発者ブログ
CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま
2026年3月19日、Aqua Security が提供するOSSセキュリティスキャナ Trivy のエコシステムが、3週間以内に2度目のサプライチェーン攻撃を受けました。攻撃者は aquasecurity/setup-trivy および aquasecurity/trivy-action の2つのGitHub Actionsに悪意あるコードを注入し、これらを利用するCI/CDパイプラインからクレデンシャルを大規模に窃取するペイロードを配布しました。 本記事では、GitHub Events APIおよびGitHub上に残存するcommitデータから取得したエビデンスをもとに、何が起こっているかを記録します。その上で、取りうる対応指針を示します。 免責 本記事の目的は事態の把握と対応の促進であり、違法行為への加担・助長を意図するものではありません。ペイロードの動作は手法の理解に必要な範囲で要
GitHub Actionsを可視化するGitHub Actions OpenTelemetryの紹介 - ともにかける
GitHub Actionsはワークフロー全体の実行時間や各ステップの詳細な可視化、変更による効果測定を行うには工夫が必要となります。この記事では、OpenTelemetryを活用してGitHub Actionsの実行結果をトレースとメトリクスの形で収集するGitHub Actions OpenTelemetryを紹介します。どのステップに時間がかかっているのか、改善施策の効果がどの程度あったのかを把握しやすくなるため、ワークフローの継続的な改善を目指す方に役立ちます。 Trace Sample (Jaeger) 1. GitHub Actionsにおける課題 1-1. ワークフローの詳細を可視化する方法が提供されていない 1-2. ワークフローの変更による影響を分析しづらい 2. GitHub Actions OpenTelemetryとは 2-1. 概要と主な機能 2-2. OpenT
弊社ウェビナー ( https://flatt.tech/takumi/event/github-actions-compromise-202603 ) におけるCTO米内の講演資料です。
こういうのを作りました。 ジョブに紐付いたPull Requestへのリンクが表示される 行ったこと: リンクを生成するジョブを1つ生やした 綺麗な表示はStep Summary機能 (後述) の力を借りている ジョブ実行画面からPull-Reqに戻りたい GitHub Actionsのジョブ実行画面には、その実行元となったPull Requestへのリンクが存在しないため、困っていた。 よくあるシチュエーション: Pull Requestを見るとジョブがコケていた 様子を見に行くうちに履歴がどんどん深くなる -- ジョブ画面内での遷移はどんどんヒストリが積まれる Pull Requestに戻れなくなってしまう この話を同僚にしたところ共感の嵐だった。したがって隠れた需要がありそうだということが判明し、うまくやる方法を考えることにした。 結果、GitHub Action上でPull-Req
11/10に突如素晴らしいアップデートが来たので、興奮冷めやらぬうちに公式よりちょっとだけ詳しい解説を書きます。 GitHub Actionsは素晴らしいCI/CDサービスであり、特にpush, pull-request, その他あらゆるGitHub上の行動をトリガーにしてワークフローを起動させる設定を簡単に書くことができます。しかし、手動でワークフローを起動させる機能の追加は他のトリガーに比べて後発でしたし、パラメータを入力するための機能やUIが少々貧弱と言わざるを得ないものでした。 一方、古より存在するJenkinsはpush, pull-requestなどの自動トリガーを設定するのは難易度が高かった[1]反面、手動でジョブを起動する機能やUIは充実していました。基本の自由テキスト以外に、プルダウンによる選択、booleanのチェックボックス、Jenkinsに登録したシークレットからの
GitHub ActionsのJobが落ちたときに何をするべきかを記述するPlaybookの仕組みを作って運用している話 - newmo 技術ブログ
newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo
ubuntu-latest から ubuntu-slim へ移行しよう！コスト削減うれしい〜！ - #あすみかんの上にあすみかん
ubuntu-slimとは github.blog 2025/10/28にパブリックプレビューとなったランナーです。 公式のchangelogにも書かれていますが、従来の ubuntu-latest と比較した際に特筆すべき違いは以下の3点です。 VMではなくコンテナ 1vCPU / 5GB RAM 15分上限 VMではなくコンテナ ubuntu-latest はジョブごとに VM（仮想マシン）を起動して動作しますが、ubuntu-slim はコンテナベースのランナーで動作します。 「ハイパーバイザーレベル2の分離（hypervisor level 2 isolation）」と書いてあり、VM のような独立した環境を提供しつつ、コンテナ特有の軽さと起動速度を両立しています。 1vCPU / 5GB RAM ubuntu-slim は1vCPU / 5GB RAM です。 ubuntu-la
きっかけ スプリントで実装した内容をリリースする際、リリースノートを毎回作成しています。 GitHub のリリースノート自動生成機能も便利なのですが、それでも「毎回ボタンをクリックする一手間が面倒だな。自動化したいな〜」と思っていました。 そこで、結構前に勉強も兼ねてリリースノート自動作成のアクションを自作したところ、チーム内で好評だったのでご紹介したいと思います。 （色々あってすっかり記事にするのが遅れてしまいました・・） 要件 main ブランチにマージされたら自動でタグとリリースノートが生成されること リリースノートには前回リリースとの差分が表示されること 同日に複数回リリースしても識別できること リリースノートのテンプレートを指定できること 完成形はこちら いきなりですが、生成されるリリースノートはこんな感じです。 完成形のアクションはこちらになります。 name: Create
GitHub Actionsを使いこなせ！/Get Started GitHub Actions
OCHaCafe Season7 #3の資料です．
改善戦略 実行のタイミングやGitHubの状況や依存サーバーのネットワークの状況によって変動はあるものの、早くて7分、だいたい10分〜15分くらいかかっている。早いか遅いかは、他の開発と比べても内容や状況が違うのでなんとも言い難いが、個人的な感想としては「遅い」。というより、一切の工夫をしていなかったので、もっと早くできるはずだと考えた。 ビルドされたファイルを複数の環境で共有する 処理全体の中で時間がかかっている処理は3つ。 依存パッケージのインストール ビルド テスト さらに、課題の一つとして「テスト実行時に開発用依存パッケージ（devDependencies）がインストールされているせいでテストが失敗しない問題がある」というものがあり、これを処理に追加しないといけない。 開発用依存パッケージのインストール ビルド 依存パッケージを一旦すべて削除 本番用依存パッケージのインストール テ
tfactionを導入してみた
tfactionとは 高度なTerraformのCI/CDをGitHub Actionsで簡単に実現できるActionです。 TerraformのCI/CDを組むにあたって欲しい機能が多く搭載されており、OSSのActionを会社のセキュリティポリシーで使えないとかがない限り、個人的にはこれを使用しないという選択肢がない位、非常におすすめなActionです。 詳しくは、開発者であるShunsuke Suzuki氏のブログを参照下さい。 導入目標 以下機能を使えること Support Monorepo with GitHub Actions build matrix ワークフロー設定ファイルを各ルートモジュール共通で管理しつつ、変更があったルートモジュールのみCI/CDを実行できる機能 tfactionを使用せず、ワークフローの発火条件でパスフィルターを設定する方法もあるが、各ルートモジュー
⚠️ Amazon から送信される Kindle のメールに仕様変更があり、現在動作しません。何かいいアイデアがあればコメント下さい。 はじめに いきなりですが、みなさん読書の管理ってどうしていますか？ 僕は、ブクログ というサービスを使っています。以前は、読書メーター を使っていたんですが、ブクログは本に記載されている ISBN コードや Amazon の Asin コードから本を登録できる[1]ということを知って最近移行しました。 どうせなら自動化したいなと思い、調べてみました。すると同じことを考えた先人たちがいらっしゃったので参考にしつつやってみることにしました。当記事はその紹介です。 作ったもの Kindle で書籍を購入した際に Amazon からメールが届きます。そのメールから使いたい Asin コードだけを抜き出して、購入した書籍をブクログに登録します。その際、処理のログをス
本記事では 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にコミットをプッシュしていくぞ〜〜」 「ローカルでコミットした変更をgit push origin mainして、、」 「github.comのレポジトリを見にいくと、、お！反映されているな！Initial Commitってちゃんと出ているぜ！」 「そういえば、いつも気にしていなかったけどActionsタブってのがあるな？これってなんだ？」 これがGitHub Actionsです。レポジトリごとに用意されていて、Actionsタブから管理、確認することができます。 「ほ〜。GitHub Actionsっていうのか・・なんのためにあるんだろう？ここで何ができるの？」 GitHub Actionsとは GitHub ActionsはGitHubがサービスの一環として提供する、ワークフロー自動化サービスです。 簡単に言えば、「開発している時にやりたいこと
はじめに 現代のアプリケーションは外部サービスのAPIキーなど様々なクレデンシャルを持つことが多いです。 これらを開発者間で安全に共有するには sops、 doppler、 git-crypt などのツールが使えます。 また、開発時はこれらのクレデンシャルを direnv などを使って環境変数に設定することも多いのではないでしょうか。 しかし、これらはどれも追加のツールをインストールする必要があります。 もし1Passwordを使っているチームに属しているなら1Passwordでクレデンシャルを管理して、それを環境変数にセットできると新たなツールを導入する必要がなくて楽です。 この記事ではそれを実現する手順を紹介します。 CLIの設定 まず1PasswordのCLIをインストールします。これで op コマンドが使えるようになります。
GitHub Actions Workflow チェックリスト | CyberAgent Developers Blog
GitHub Actions Workflow Best Practices こんにちは。2022年新卒入社の上田です。現在は本配属前のジョブロで ABEMA に所属しております。 この記事では GitHub Actions workflow/job 作成に関するベストプラクティスをまとめました。 workflow/job 追加時に参照できるチェックリストとしてご利用いただけるような一記事として公開しています。堅牢で安全な CI/CD pipeline を作る参考になれば幸いです。 （ジョブロ：メディア事業部における新卒研修の一環として二ヶ月間実施される本配属前のジョブローテーション研修） 自己紹介 GitHub Actions は Beta v1 の頃から利用しており、個人としても peaceiris/actions-gh-pages などをはじめとして、いくつかのサードパーティー Ac
Prologue こんにちは、 @dz_ こと、大平かづみです。 今回はこのブログ記事 "5 automations every developer should be running" が気になったので、ちゃんと読むついでに要約してみました。（ブログ駆動） なお、英語の能力は高くないので、誤訳などありましたらご連絡いただけたらうれしいです🙇🏻♀️ 要約: "5 automations every developer should be running" TL;DR: セキュリティ脆弱性との闘いや動かないボタン、遅いサイト、リリースノートを手書きすることを避けたいエンジニアの君に捧ぐ テストを書くことや改善のための自動化を行うことは大事ではあるが、実際のところもっとコードを書いた方が楽しい！ さいわいなことに、GitHub Actions ではたくさんのコミュニティで作られたテストや
はじめに こんにちは！Hamee株式会社の tatsuo48 です。 GitHub ActionsにはデフォルトでGITHUB_TOKENというシークレットが存在しており、環境変数にセットして利用することで、Actionsがトリガーされたリポジトリに対する操作が可能です。 GITHUB_TOKENシークレットについて これはこれで便利なんですが、特定の条件のときに少し問題があります。 CIの中で別リポジトリを使いたいときどうする問題 上記の通り、GITHUB_TOKENでは権限の範囲がActionsがトリガーされたリポジトリに制限されます。よって以下のようなユースケースには適しません。 CIの中で別のプライベートリポジトリを参照したい Terraformのプライベートモジュールとか こういった場合、マシンユーザという人に紐付かないユーザを作り、そのユーザの個人アクセストークンが使われたりす
ユニットテストをGitHub ActionsからCodeBuildに移行し、実行時間を35%削減した - Uzabase for Engineers
こんにちは。NewsPicks SREチームの 海老澤 です。 今回はGithub Actionsで実行していたテストを高速化したので紹介したいと思います。 課題 取り組み テストの並列化 AWS CodeBuildへの移行 CodeBuildの設定 コンピューティングタイプ トリガー buildspec.yml 結果 課題 NewsPicksでは Junitのテスト等をGithub Actions から実行しているのですが、2013年のサービス開始当初から存在する、一番コードベースが大きいリポジトリのビルド・テストの実行時間に 20~30分ほどかかっていました。 テスト自体はバグを産まないためにも必要なものですが、時間がかかるため開発効率が下がってしまいます。そのためテスト高速化の取り組みを行いました。 取り組み テストの高速化をする上でやったことは大きく下の二つです テストの並列化 G
スタディサプリの開発運用を支える GitHub Actions - スタディサプリ Product Team Blog
こんにちは。SRE の @int128 です。 スタディサプリのプロダクト開発では GitHub Actions を積極的に導入しています。本稿では、日常の風景に溶け込んでいる GitHub Actions を紹介します。 プロダクトの開発運用を支える GitHub Actions リポジトリとオーナーシップ 我々は monorepo を採用しており、すべてのマイクロサービスを同じリポジトリで管理しています。リポジトリのディレクトリ構成は下図のようになっています。 . ├── .github/workflows/ │ ├── マイクロサービス--test.yaml │ ├── マイクロサービス--deploy.yaml │ ├── ... │ └── reusable--横断的関心事.yaml ├── マイクロサービス/ │ ├── README.md │ ├── プロダクションコード..
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[アップデート] Amazon CloudWatch RUM にセッションリプレイ機能が追加され、ウェブアプリケーションのユーザー操作を動画のように再生できるようになりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/4c036df551bce6d942cabbdd11e335b08af200f3/backend=imagemagick;height=288;version=1;width=512/https%3A%2F%2Fimages.ctfassets.net%2Fct0aopd36mqt%2Fwp-thumbnail-d6a3bc85cad6419960fbda152152cd8c%2Fba5841cea06b96f4933878762028b090%2Famazon-cloudwatch)
もう初回コードレビューはAIに任せる時代になった - CodeRabbit -
GitHub Actions 逆引きリファレンス
入門 GitHub Actions - メドピア開発者ブログ
GitHub Actions で簡単にバージョン番号付きリリースとリリースノートを作成する方法
なんとなくから脱却する GitHub Actionsグッドプラクティス11選 | gihyo.jp
GitHub ActionsにおけるStep/Job/Workflow設計論
freeeの自動テストの全体構成 - freee Developers Hub
共同開発を始めるときに便利な 5 つの GitHub Actions
Claude CodeとGitHub Issueを使った全自動開発について
GitHub Actionsのワークフローを可視化するactions-timelineを作った
GitHub Actionsと"仲良くなる"ための練習方法
GitHub Actionsをローカルで実行する(nektos/act) - くらげになりたい。
2026年3月19日の Trivy 再侵害の概要と対応指針
GitHub Actions侵害 — 相次ぐ事例を振り返り、次なる脅威に備える
GitHub Actionのジョブ実行画面からPull Requestを辿れるようにした - Lambdaカクテル
GitHub Actionsの手動実行パラメータのUI改善について速報で解説する
GitHub Actionsでいい感じのリリースノートを完全自動で作成する
ジョブを細かく分けてGitHub Actionsのテストを効率化する
Kindle で購入した書籍をブクログへ自動で登録する
pull_request_target で GitHub Actions の改竄を防ぐ
GitHub Actionsって何？触ってみて理解しよう！入門・逆引きリファレンス - Qiita
1Password の CLI で環境変数を管理する
Check! GitHub Actions で導入しておきたい自動化 5つ（GitHubブログ要約）
そのマシンユーザー不要ですよ！GitHub Appsを使ってGitHub Actionsを利用しよう
hint-pot.jp
chiilop.com
www.jstor.org
leetcode.com
youtu.be
leetcode.com