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
January 25, 2022 You can now reference local reusable workflows more easily. With this release, reusable workflows that are in the same repository as the calling repository can be referenced with just the path and filename: {path}/{filename}. For example: jobs: call-workflow-in-local-repo: uses: ./.github/workflows/workflow-2.yml When referenced this way, the called workflow will be from the same
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