ネタです。 GitHub Actions の runner 上のエミュレーターで、アプリが正常に起動できるかのみをチェックするワークフローです。Renovate や Dependabot のようなボットが作成するプルリクで動かすと、少なくとも起動できるところまではこのワークフローで担保できるのでよいかも。 普通に Espresso 等で起動を確認するテストコードを用意してもよいのですがネタなのでw name: Launch Check on: pull_request jobs: check: runs-on: macos-latest steps: - name: Check out uses: actions/checkout@v4 - name: Set up JDK uses: actions/setup-java@v3 with: distribution: 'zulu' jav
GitHub Actionsでは依存パッケージやビルド結果などをうまくキャッシュすることで、テストやビルドの時間を短縮できます。 actions/setup-nodeやactions/setup-javaなどの各言語のオフィシャルアクションは各パッケージマネージャーのためのキャッシュ機構を提供していますし、actions/cacheを使って任意のファイルをキャッシュすることもできます。 これらは内部で@actions/cacheパッケージを使っており、キャッシュの機構はGitHub自身の機能と密に結びついています。 しかし、GitHub Actionsのキャッシュはリポジトリごとに10GBまでという制限があり、開発者の多いリポジトリではsetup-nodeのキャッシュだけでもすぐに上限に達してしまいます。 私の所属するチームのリポジトリはGitHub Enterprise Serverにホ
github.blog GitHub Actions の新バージョンが 8/8 に発表されました。 www.kaizenprogrammer.com 自分は過去にも旧バージョン時に GitHub Actions の入門記事を書いていたのですが、新バージョンがこれまでと大きく変わってしまっているので、この記事ではあらためて GitHub Actions についていろいろ調べたり動かしてみたりした内容をまとめます。 目次 注意事項 GitHub Actions とは これまでの GitHub Actions とどこが変わったか コンセプト マルチプラットフォーム対応 HCL から YAML へ 料金 その他 GitHub Actions と Azure Pipelines 簡単な例 (Hello, World) ワークフローの設定 ワークフローとは ワークフローを実行するイベント ワークフロー
GitHub Actionsを利用してFlutterアプリをビルドする場合、ビルド前にSDKをいちいち設定する必要があります。下の例ではそれに1分近くかけており、CIの時間をかなり圧迫していることがわかります。 GitHub Actionsにはキャッシュの機能が存在するため、Flutter SDKをキャッシュすることでCI時間を大幅に削減することが見込めます。 1.Cacheアクションを使う #...略... 'on': push: branches: - master env: flutter_version: '2.10.0' jobs: build_and_deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: search flutter cache uses: actions/cache@
概要 どうも、@daiki1003です!Flutterでもなんでもそうですが、普段開発をする上で 安定して高品質なプロダクトをリリースしなければならないため、CIは欠かせない存在になっていますね。 そんな必要不可欠なCIですが、1秒でも早く終わってほしいですよね? 毎回のことなので、少しでも改善できれば複利のように効いてくるので ぜひ本記事を読んで使えるところは使ってみてくださいね! 最終的に完成したyamlも貼り付けるのでコピペで 使えると思いますよ 👍 今回CIの改善で行ったのは下記3点です。 ・Flutterインストールのキャッシュ ・flutter pub getのキャッシュ ・build_runnerのキャッシュ では行ってみましょー! Flutterのインストールのキャッシュここだけやるだけでも結構効果的ですね。 やり方は2通りあると思います。 ・subosito/flutt
こんにちは、フロントエンドエンジニアの小張です。GitHub Actionsの実行時間を削減するために取り組んだことについて紹介します。 経緯 PR TIMESではReactに関するコードを、monorepoとしてprtimes-frontendという1つのリポジトリで管理しています。 GitHub Enterprise Cloudプランでは月50,000分のGitHub Actionsを無料で実行することができますが、prtimes-frontendだけで7割近い時間を消費してしまっていました。またCIに時間がかかることで、Pull Requestを作成した後、10分近く待たないとコードレビューに回すことができず、開発効率が落ちてしまっていました。 そこで現状の使い方を見直して、billable timeの削減に取り組むことになりました。 billable time削減の改善点を探す b
GitHub Action上でflutterのテストを実行した結果を見るとき、jobの実行ログを見るのは少し大変ですよね。どれが成功/失敗したかひと目では分かりづらいですし。 今回は↓のようにテストの結果を見やすい形でChecks上に表示する方法を紹介します。 事前準備 特にありません。テストファイルを準備し、flutter testでテストが実行できる状態にします。 ymlファイルの作成 まずはワークフローを実行するためのymlファイルを、リポジトリ内の.github/workflowsに作成します。名前はお好みで。ここではtest.ymlとします name: test on: workflow_dispatch: pull_request: types: [opened, synchronize] push: branches: - main env: FLUTTER_VERSION:
注記: GitHub では、前もって利用ベースのコスト値に対して一時的に承認が保留となることがあります。これは、アカウントの支払方法に保留中の請求として表示されます。 GitHub Actions の使用は、パブリック リポジトリの標準の GitHub ホステッド ランナーとセルフホステッド ランナーの場合は無料です。 プライベート リポジトリの場合、アカウントのプランに応じて、GitHub ホステッド ランナーでの使用を対象として、一定量の無料の使用時間 (分) とストレージが各 GitHub アカウントに付与されます。 含まれる量を超える使用は、使用制限によって制御されます。 月ごとの請求のお客様の場合、アカウントには既定の使用制限として 0 米ドル (USD) が設定されます。これにより、プライベート リポジトリで、そのアカウントに含まれる容量を超える追加の時間 (分) やストレージ
1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く