GitHub Actionのジョブ実行画面からPull Requestを辿れるようにした - Lambdaカクテル
こういうのを作りました。 ジョブに紐付いたPull Requestへのリンクが表示される 行ったこと: リンクを生成するジョブを1つ生やした 綺麗な表示はStep Summary機能 (後述) の力を借りている ジョブ実行画面からPull-Reqに戻りたい GitHub Actionsのジョブ実行画面には、その実行元となったPull Requestへのリンクが存在しないため、困っていた。 よくあるシチュエーション: Pull Requestを見るとジョブがコケていた 様子を見に行くうちに履歴がどんどん深くなる -- ジョブ画面内での遷移はどんどんヒストリが積まれる Pull Requestに戻れなくなってしまう この話を同僚にしたところ共感の嵐だった。したがって隠れた需要がありそうだということが判明し、うまくやる方法を考えることにした。 結果、GitHub Action上でPull-Req
GitHub Actions 逆引きリファレンス
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における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
Cloud RunをGithub ActionsとTerraformで管理する
. ├── backend.conf ├── main.tf ├── registry.tf ├── terraform.tfvars └── variables.tf main.tfでは、terraformのバージョン指定とサービスアカウントのroleの指定が定義されています。repo_nameは権限を与えるgithubリポジトリなので、この段階で連携するリポジトリを決めておく必要があります。 terraform { required_version = "~> 1.1.9" backend "gcs" { prefix = "terraform/state" } } locals { cloudrun_roles = [ "roles/run.developer", "roles/iam.serviceAccountUser" ] } resource "google_project_
GitHub - rhysd/actionlint: :octocat: Static checker for GitHub Actions workflow files
actionlint is a static checker for GitHub Actions workflow files. Try it online! Features: Syntax check for workflow files to check unexpected or missing keys following workflow syntax Strong type check for ${{ }} expressions to catch several semantic errors like access to not existing property, type mismatches, ... Actions usage check to check that inputs at with: and outputs in steps.{id}.output
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 チートシート
概要 何度も調べて何度もテストしたりしたので、多用するものをまとめていきたい。 項目 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 Projects (Beta) に Issue を自動登録・削除する Actions を作ってみた
はじめに みなさん、GitHub Projects (Beta) 使ってますよね？ え？まだ使ってない？そりゃぁ勿体ない！ 今すぐ GitHub Issues の Sign up for the beta ボタンをクリックしてください！ 豊かなプロジェクト管理ライフが貴方を待っていますよ！！！ はい、というワケで深夜の謎テンションで記事を書き始めてみました。 Projects (Beta) 未使用の方向けに粗く概要を説明すると、GitHub Projects (Beta) は次のような特徴をもった GitHub のプロダクトです。 Board（いわゆるカンバン）や Table（Excel/Spread Sheet 的な表形式）で Issues, Pull Requests を管理できる User/Orgs の配下に Project を作成し、複数のリポジトリの Issues, Pull R
GitHub Actionsで特定のディレクトリ配下が変更されたときだけワークフローを発火する - tom-256.log
概要 GitHub Actionsで特定のディレクトリ配下のファイルが変更されたときにワークフローを発火する方法。 結論 トリガーにpathsを使用する。 下記のように書くとhogeディレクトリ配下のファイルが変更されたときのみワークフローが発火する。 on: push: paths: - 'hoge/**' https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths ユースケース モノレポで各ディレクトリの変更に対して個別にワークフローを発火する 特定の拡張子が変更された場合のみ発火する ドキュメントの更新でワークフローを走らせたくない など まとめ 最近モノレポプロジェクトを触っているのでまとめた。
GitHub Actions のベストプラクティス
1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。
Next.jsプロジェクトにCypressを導入してGitHub ActionsでE2Eテストをする
はじめに ※この記事は下記記事の延長です。下記記事を読まなくても問題ないように書いていますが、ご興味ありましたらご一読ください。 今回はNext.jsプロジェクトにCypressを導入してGitHub ActionsでVercelのPreview環境のE2Eテストをするまでの手順を書いていきたい思います。 前提 Next.jsでsrcディレクトリ配下にアプリケーションコードを配置していること Vercelを使用しており、PRごとにPreview環境がデプロイされること 導入手順 必要なパッケージをインストール npm scriptsをpackage.jsonに追加 yarn cy:openを実行し雛形を作成 設定ファイルを修正し初めてのテストを実行 TypeScript対応 @testing-library/cypressの設定 GitHub Actionsの設定 必要なパッケージをインス
GitHub Actions のデバッグをローカルで行う
概要 GitHub Actions で GitHub ホストランナーを使用する場合、パブリックポジトリは無料ですがプライベートリポジトリは従量課金（無料枠あり）です。 ワークフローを編集する際にデバッグしていると結構な時間を消費してしまいます。 そこでデバッグ時は GitHub ホストランナーを使わずに無料で実行する方法を 3 種類紹介します。 nektos/act 言わずと知れたローカル実行ツールです。 すべてを再現することはできませんがコミットを増やさずにデバッグができます。 注意点 ubuntu-* のみサポート ソフトウェアは指定する Docker イメージ依存、デフォルトのイメージだと色々足りないので -P で指定 secrets.GITHUB_TOKEN が未定義なので Personal Access Token を発行し設定が必要 サービスコンテナ services が使えな
GitHub Action で特定のディレクトリ配下に変更があったときのみワークフローを実行する | 35D BLOG
⚠ この記事は最終更新日から1年以上が経過しています。内容が古い箇所がある可能性があるためご注意ください。 on.<push|pull_request>.paths / GitHub Docs過去の自分に早くこの事実を伝えてあげたい気持ちでいっぱいなので、この記事を書きました。 僕たちのプロダクトは yarn workspace を使用しており、1つのリポジトリで複数のパッケージを管理しています。このような構成の都合上、GitHub Actions のデフォルトの設定だと、パッケージAに変更があった際に、パッケージBのワークフローも実行されてしまうという課題がありました。 そこで僕は、git のログから diff を取り、ファイル名を再帰的に見てゴニョゴニョしていけば、不要なワークフロー実行をスキップできるのでは？と思っていろいろ調査していました。しかし、結論、そんな複雑なことは必要なく、
Run your Github Actions jobs from a specific directory
I am working on a current project where the Backend and the Frontend of the application are on the same repository of Github. That's why I faced a situation to run the Github Actions jobs for my React app from a specific directory. And, I find a quick solution to it. Specify for all Jobs: Github actions have a working-directory option to declare on workflow. It specifies the working directory for
Nuxt利用プロダクトでIE11と仲良くするためのE2E - メドピア開発者ブログ
フロントエンドなエンジニアの皆さま、ご機嫌いかがでしょうか。 唐突な質問ですが、Internet Explorer 11というブラウザはお好きでしょうか。勿論大好きであられるかと存じ上げます。Webの歴史をまさにその身をもって築き上げてきた由緒正しきブラウザであります。唯一無二の王道です。昨今は様々なブラウザが溢れてあそばせております。しかし所詮それは一時的なこと。やがて全人類は母なるInternet Explorer 11の元へと還っていくことでしょう。 我々が目指したこと Internet Explorer 11（以下、IE11）を目にすること、操作すること、その他あらゆる接点を限りなく減らしつつ、プロダクトがIE11でも動作可能なことの検証と保証を行いたい。 これを成し遂げるエンジニアリング的な手段、つまりIE11環境でのE2Eテストを自動化することを目指します。 環境 自動化を行う
Cloud Run と GitHub Actions を使って Pull Request 単位でプレビュー環境を立ち上げる - wadackel.me
はじめに 最近 Google Cloud Platform の Cloud Run が GA となったのが話題に上がりました。また gcloud コマンドを GitHub Actions 上で簡単に扱うための GoogleCloudPlatform/github-actions もリリースされました。これまで使われることの多かった actions/gcloud は deprecated となりアーカイブされています。 これらのサービス、ツールを使うことでかなり簡単に Docker コンテナを動かす環境を構築できます。そのユースケースの一つとして、実際に僕が携わっているプロジェクトでレビューコスト低減のために行っている、Pull Request (以下 PR) 単位で独立したプレビュー環境を起動する方法についてメモがてらブログにまとめようと思います。 前提 以下のようなアプリケーション、プロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Using Github Actions with Railway
Deploying To Serverless Platforms With GitHub Actions - Global Cloud Platforms
Run eslint with reviewdog - GitHub Marketplace
GitHub - nektos/act: Run your GitHub Actions locally 🚀
