やんないほうがいいかも、GitHub Actions の setup-xxx での依存キャッシュ保存 - 誰かの役に立てばいいブログ
GitHub Actions で CI している皆様、こんにちは。 GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えば Go で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
ファインディでのGitHub Actions高速化の事例 - Findy Tech Blog
ファインディ株式会社でフロントエンドのリードをしております 新福(@puku0x)です。 弊社では、数年前に社内のCI環境をすべてGitHub Actionsに移行しました。 この記事では、弊社のGitHub Actions活用事例の内、CI高速化についてご紹介します。 なぜCI高速化に力を入れるのか CI高速化 キャッシュの活用 ジョブの並列化 Larger Runners まとめ なぜCI高速化に力を入れるのか 当ブログをはじめ弊社では、たびたびCI高速化の大切さについて言及しています。 Findyの爆速開発を支えるテクニック - Findy Tech Blog RailsのCIのテスト実行時間を 10分から5分に高速化した話 - Findy Tech Blog Findy転職フロントエンドの開発生産性を向上させるためにやったこと - Findy Tech Blog これはなぜでしょう
Visual Regression Testをサポートするreg-actionsをリリースした
Visual Regression Test(以下VRT)をやろうと思うと画像をどこに保存するかを検討する必要がでてくるケースがある。 (web アプリケーションのVRTを前提とすると)多くの場合、テキスト形式である*.snapとは異なり、画像取得時のOSやfont、ブラウザのversionなどにより差分がでやすくなってしまう。そのため画像はCIなど環境を極力そろえた状態で取得し、S3などに上げVRT対象の画像を管理するケースがみられる。 今回はこのフロー・管理の簡略化を目指しactionsを作成・リリースした。 成果物 repositoryは以下。yamlに後述するstepを記述すれば使用できる。 セットアップ 最小の記述は以下となる。これで./images以下の画像に対してVRTを行ってくれる。VRTに必要な画像管理はactionsが受け持ち、PRごとにレポートをコメントする。 nam
GitHub ActionsでJestのログに色をつけられる - hogashi.*
Jest は TTY では色つきのログを出すが、そうでないときは色なしになる https://jestjs.io/docs/cli#--colors --colors オプションか、環境変数で FORCE_COLOR=true するととにかく色つきのログを出せる GitHub Actions では色つきのログに対応している A better logs experience with GitHub Actions | The GitHub Blog That’s why we are increasing the color support, including: ANSI colors 8-bit colors 24-bit colors https://github.blog/2020-09-23-a-better-logs-experience-with-github-actions/
Mackerelのサービスメトリックを簡単に投稿するためのGitHub Actionsを作った - stefafafan の fa は3つです
このエントリは Mackerel Advent Calendar 2022 および GitHub Actions Advent Calendar 2022 の20日目の記事です。*1 今回はMackerelのサービスメトリックを投稿するためのGitHub Actionsを新規で作ったのでその紹介をします。 GitHub Actions経由でメトリクスを簡単にMackerelに投稿したい 既存のGitHub Actions yutailang0119/action-mackerel-api susisu/setup-mkr 自分のユースケースでの気になり stefafafan/post-mackerel-metrics の紹介 実際に活用している事例 テクニック紹介: 他のStepからMultiline Stringの受け渡し 初めて作ったGitHub Actionについての感想や困りなど
Docker コンテナの起動を待つ - MySQL の使い方 - [GitHub Actions]
概要 Docker コンテナを扱う際に起動を待ちたいケースは多々あると思います。 この記事では MySQL コンテナを例に3パターンと、 Docker ではないのですが MySQL の場合プレインストールもされているので併せて紹介します。 TL;DR 長々と説明していますが重要なポイントはこの2つです。 Docker コンテナのヘルスチェック CLI から起動する場合は until や docker compose up -d --wait で待機 プレインストール GitHub ホストランナーには MySQL や PostgreSQL がインストールされています。 最初は無効化されているので sudo systemctl start postgresql.service で有効化します。 すぐに使える状態になるので起動時間は最速です。 jobs: pre-installed: runs-
![Docker コンテナの起動を待つ - MySQL の使い方 - [GitHub Actions]](https://cdn-ak-scissors.b.st-hatena.com/image/square/dd02792f18be867342593c9d8152897cf17dea07/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--zkmE98Z_--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3ADocker%252520%2525E3%252582%2525B3%2525E3%252583%2525B3%2525E3%252583%252586%2525E3%252583%25258A%2525E3%252581%2525AE%2525E8%2525B5%2525B7%2525E5%25258B%252595%2525E3%252582%252592%2525E5%2525BE%252585%2525E3%252581%2525A4%252520-%252520MySQL%252520%2525E3%252581%2525AE%2525E4%2525BD%2525BF%2525E3%252581%252584%2525E6%252596%2525B9%252520-%252520%25255BGitHub%252520Actions%25255D%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3A%2525E9%25259B%2525AA%2525E7%25258C%2525AB%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EtL0FPaDE0R2dsdnpGMmRXRHdxQlZmQ0hHd2Z6bV9PTW5YeTZjVElKVm1WOVV4Tmc9czI1MC1j%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
特定のユーザーのイベントによるGitHub ActionsのActionを保留状態にしておき、後で手動実行できるようにする - その手の平は尻もつかめるさ
dependabotだとかrenovateだとかを使ってライブラリのバージョンアップのpull requestを自動的に送ってもらう、というような機構を利用されている方が多いと思います。 常にこれらのpull requestに目を光らせておいて常に取り込み続けるというのが理想的な形・そうあるべきだとは思うのですが、ふと気を抜くとバージョンアップのpull requestが溜まっていき、pull request自身も改訂に改訂を重ねている......みたいなことが起きがちではないでしょうか。 そういった折、誰も結果を見もしないCI (i.e. GitHub Actions) だけが回り続けているのを見て「このチェックは『ライブラリアップグレード業』をやる時に手動で回せばコンピューティングリソースの削減になるのでは？」と思い、それを試したという次第です。 この記事では例として、renovate
Dependabot が起動する GitHub Actions Workflow から write 権限が無くなった件
Dependabot から送られてくるプルリクエストのテストが最近良くコケるようになったなあと思ったら、 3 月 1 日から GitHub Actions Workflow 内の GITHUB_TOKEN のパーミッションが変更になったそうです。 GitHub Actions: Workflows triggered by Dependabot PRs will run with read-only permissions 更新されたパッケージに secrets を盗み見るような危険なコードが含まれているかもしれません。 そのようなコードでも安全に実行できるよう read-only のパーミッションで実行されるようになりました。 その結果以下のようなワークフローが失敗するようになってしまいました。 プルリクエストにラベルをつけるような、レポジトリに対して write パーミッションが必要な
GitHub ActionsにおけるStep/Job/Workflow設計論
この記事について 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
Supercharging GitHub Actions with Job Summaries
ProductSupercharging GitHub Actions with Job SummariesYou can now output and group custom Markdown content on the Actions run summary page. The same familiar functionality that powers pull requests, issues, and README files has come to GitHub Actions! We’re thrilled to announce GitHub Actions Job Summaries, which allow for custom Markdown content on the run summary generated by each job. Custom Ma
令和最新版 actions-cache-s3
Cache dependencies and build outputs in GitHub Actions (support S3 backend for @actions/cache) - GitHub - whywaita/actions-cache-s3: Cache dependencies and build outputs in GitHub Actions (support ... つくりました。 これはなに GitHub Actionsにはactions/cacheというものがあって、ビルド時の依存関係を解決したものとかをキャッシュしておくことができます。 標準ではGitHubが提供するキャッシュサーバにファイルが保存されるんですが、さまざまな事情により自分たちが管理するストレージに置きたいことがあります。 AWSなどでself-hosted runnerを運用しているG
GitHub Actionsのpushイベントとpull_requestイベントではGITHUB_SHAが異なる - くりにっき
tl;dr; 検証内容 サンプルコード masterブランチに普通にpushした時 PullRequestに対してpushした場合 pushイベントの結果 pull_requestイベントの結果 解説 2021/01/08 追記 GITHUB_SHAが異なることで何が困るか 余談：tfnotifyでpull_requestイベントの時にもPullRequestにコメントをつけたい FAQ Q. だったらpull_requestは不要では？ 今の心境 tl;dr; タイトルが全て 検証内容 サンプルコード GitHub Actionsで使える（事前定義済みの）環境変数 *1を列挙するだけのシンプルなワークフローです on: - push - pull_request jobs: show_env: runs-on: ubuntu-latest steps: - run: env | grep
GitHub ActionsでDocker Buildするときのキャッシュテクニック - cockscomblog?
GitHub Actionsでdocker buildすることが多い。このときのキャッシュをどうするかという話題。 基本 GitHub Actionsでdocker buildしてAmazon ECRにdocker pushする、典型的な.github/workflow/docker-push-to-ecr.ymlはこういう感じ。 name: Push to Amazon ECR on: push: branches: [ 'main' ] jobs: docker: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: docker/setup-buildx-action@v1 - name: Configure AWS credentials uses: aws-actions/configure-aws-c
GitHub Actions: Reusable workflows can be referenced locally · GitHub Changelog
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
actions/virtual-environments を我が手に！セルフビルドしてみた | CyberAgent Developers Blog
この記事はCyberAgent Developers Advent Calendar 2021 10日目の記事です。 昨日はみーとみさんの「待機児童問題にマーケットデザインで挑む」でした。 はじめに CIU (CyberAgent group Infrastructure Unit) の中西 (@whywaita) です。 普段はプライベートクラウドであるCycloudのIaaSから上のレイヤーを中心に開発運用を担当しています。 直近ではGitHubからリリースされているGitHub ActionsというCIサービスに関連したmyshoesというソフトウェアを開発しています。 myshoesはOSSで公開されており、直近でもいくつかmyshoesについて登壇させていただいたので興味のある方はぜひこちらをご覧ください。 CyberAgent における OSS の CI/CD 基盤開発 mys
保護ブランチへの直 push を禁止する
要約 特定のブランチへの直 push を禁止するためにはブランチ保護ルールを追加するだけでは足りず、マージ前の PR またはステータスチェックを必須にする必要があります。 保護ブランチ 目的 意図しない変更が入らないようにブランチを保護します。 設定方法 リポジトリの Settings > Branches > Branch protection rules > Add Rule で設定できます。 Branch name pattern に保護したいブランチ名を入力します。 パターンも使えるので milestone/* のような指定もできます。詳細はドキュメント参照。 直 push を禁止するためにはマージ前の PR またはステータスチェックを有効にする必要があります。 ステータスチェックが不要であればマージ前の PR にチェックを入れれば十分です。 Include administrat
GitHub Actions で mkr を使う - Object.create(null)
mkr とは何ですか? Mackerel の CLI です. GitHub Actions 上で mkr をセットアップする setup-mkr アクションを作りました. github.com こういう感じで uses: susisu/setup-mkr@v1 と一行書くだけで mkr コマンドが使えるようになります. steps: - uses: susisu/setup-mkr@v1 - run: mkr org env: MACKEREL_APIKEY: ${{ secrets.MACKEREL_APIKEY }} mkr の詳しい使い方はここでは紹介しませんが, mkr throw で何らかのメトリックを投稿したり, mkr wrap でジョブの成否を監視したり, mkr annotations create でイベントを記録したりといったことに利用できるかなと思います. さてここ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub Actions: Simplify using secrets with reusable workflows