GitHub Actions で動的な環境変数を実現する
やりたいこと GitHub Actions のワークフローで、ある値を元に環境変数を切り替えたくなるときがたまにあります。 たとえば、 workflow_dispatch で inputs の指定をもとに環境変数が切り替えられると、一つの指定に対して複数の値を決定できるので入力をシンプルにできます。 # .github/actions/deploy-web.yml on: workflow_dispatch: inputs: environment: type: choice description: デプロイする環境 required: true options: - 開発 - 検証 - 本番 env: NEXT_PUBLIC_API_ORIGIN: |- environment == 開発 -> https://dev.api.example.com environment == 検証
.NETのGitHub Actionsワークフローでエラーが2回表示される問題の解決
問題 以下の内容の続きです。GitHub Actionsで dotnet build するだけで、コード中へのエラー指摘までしてくれる、という内容でした。 - name: Setup .NET uses: actions/setup-dotnet@v2 with: dotnet-version: 6.0.x - name: Build run: | dotnet build -warnaserror MSBuild version 17.3.0+92e077650 for .NET CSC : error CA1014: Mark assemblies with CLSCompliant [/home/runner/work/dotnet_actions_test/dotnet_actions_test/ConsoleApp1/ConsoleApp1.csproj] Error: /hom
[WWDC22] Xcode Cloudと他のCIサービスの料金を比較してみた | DevelopersIO
参考 https://developer.apple.com/xcode-cloud/ 計算に使用したプラン: (最安のプラン) $14.99 / month 25 hours / month 1分のビルドに必要な料金 1時間のビルドに必要な料金: $14.99 / 25 = $0.5996 1分のビルドに必要な料金: $0.5996 / 60 = $0.009 ≒ 1.21円(1ドル134円換算) GitHub Actions 参考 https://docs.github.com/ja/billing/managing-billing-for-github-actions/about-billing-for-github-actions https://github.com/pricing 計算に使用したプラン: GitHub Team (1 User) $4.00/month 3,00
![[WWDC22] Xcode Cloudと他のCIサービスの料金を比較してみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/ed03d6035f2043d9cf2cbb1955eb5a04a000f462/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2020%2F09%2Feyecatch-xcode.png)
GitHub ActionsでビルドしてCloudflare Pagesにデプロイする
やりたいこと Cloudflareは無料プランでも最高。今までGitHub PagesやNetlifyにデプロイしてCloudflare経由で配信してきた。Cloudflareは速くて安定している。 Cloudflare Pages のリポジトリ連携よりは GitHub Actionsで好きなビルド方式でビルドしたものをCloudflare PagesにデプロイしたいとCloudflare Pagesが発表された時から思っていた。それを可能にするGitHub ActionsをCloudflare公式が開発しているのを発見した。その使い方ともっとプレビューを活かせる方法も+αして書いていきたい。 コミットごとにプレビューのページが作成される。 プレビュー例: https://8ba3e416.cloudflare-pages-with-github-actions-prac.pages.de
GitHub Actions の "actions/cache" で作成した cache を GitHub CLI で削除する - Qiita
GitHub Actions の "actions/cache" で作成した cache を GitHub CLI で削除するGitHubGitHubActionsGithubCLI はじめに GitHub Actions の "actions/cache" で作成した cache を GitHub CLI で削除する 方法についてまとめました 事前準備 この方法は GitHub CLI が使える前提です。使えない場合は設定するか、 "curl" で実行したい人は docs を参照してください cache を削除する Cache Key を取得する GitHub Actions の実行結果を確認し、Cache Key を取得します 以下のような Log が出力されている箇所を探します 多く場合 Run actions/cache@v2 や Post Run actions/cache@v2
ubuntu-22.04 が GA ⚠破壊的変更注意⚠ [GitHub Actions]
概要 GitHub-hosted ランナーで Ubuntu 22.04 が GA になり、併せて Ubuntu 18.04 が deprecated になっています。 また Self-hosted ランナーでも Apple M1 がサポートされました。 Apple M1 サポートはようやくと言った感じですがこの記事では紹介に留め、多くの破壊的変更を含んでいる Ubuntu 22.04 へのアップデートについて注意喚起をしておきます。 ubuntu-latest を使っている人は将来的に強制アップデートされますので特に注意が必要です。 既に ubuntu-22.04 を使っている人や ubuntu-20.04 にバージョンを固定して使っている人は対応を急ぐ必要はありませんが ubuntu-18.04 を使っている人は 2022/12/01 2023/03/01 2023/04 に廃止されるの
![ubuntu-22.04 が GA ⚠破壊的変更注意⚠ [GitHub Actions]](https://cdn-ak-scissors.b.st-hatena.com/image/square/def061926e39e63ea46bc8e97d237901fe449bc4/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--cdO0umbI--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3Aubuntu-22.04%252520%2525E3%252581%25258C%252520GA%252520%252520%2525E7%2525A0%2525B4%2525E5%2525A3%25258A%2525E7%25259A%252584%2525E5%2525A4%252589%2525E6%25259B%2525B4%2525E6%2525B3%2525A8%2525E6%252584%25258F%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 のキャッシュを管理
API を使う まずは extension ではなく GitHub の API を使ってリポジトリのキャッシュを管理する場合について。 GitHub API の利用方法はいくつかありますが、今回は簡単に GitHub CLI から利用してみます。 使用量の確認 どれくらい利用しているかの確認です。 $ gh api -H "Accept: application/vnd.github+json" "/repos/{owner}/{repo}/actions/cache/usage" { "full_name": "hankei6km/xquo", "active_caches_size_in_bytes": 10572695430, "active_caches_count": 58 } $ gh api -H "Accept: application/vnd.github+json" "
GitHub ActionsでECS自動デプロイ環境を構築する（DBのmigrate処理まで） - Qiita
Github ActionsでECSにデプロイする構成自体はかなり多くの記事が出回っているので苦労はしないと思うのですが、IAMのキーの運用についてや、migrateタスクを自動で更新してコンテナを立ち上げて動かすのに少し時間がかかったので、網羅的にまとめておこうと思い、記事を書きます。 この記事の内容 IAMの作成(Assume Role) GitHubActionsの設定ファイルの書き方 GitHub Actions参考ドキュメント https://github.com/aws-actions https://github.com/aws-actions/amazon-ecr-login https://github.com/aws-actions/configure-aws-credentials https://github.com/aws-actions/amazon-ecs-d
ニュースリリース – JetBrains IDEとCIを連携させるプラグイン – CIcloneを発表 | 株式会社サムライズム
株式会社サムライズム JetBrains IDEとCIを連携させるプラグイン – CIcloneを公開 JetBrainsやGitHubなど、ソフトウェア開発者向けのツール販売を手がける株式会社サムライズム（本社：東京都豊島区、代表取締役：山本裕介、以下サムライズム）は、JetBrains IDEの生産性をより向上させるプラグイン CIcloneを発表いたしました。本日より、JetBrains Plugin Marketplaceよりダウンロードしていただけます。 お客様は、IDE内よりCIcloneをインストールすることにより、CI(継続的インテグレーション)サービスとJetBrains IDEを連携させることが出来ます。ビルド結果についての通知をIDE内で即座に受け取ることで、プルリクエスト/マージリクエストの作成や失敗したテストケースの検証を素早く行うことが出来ます。 CIclone
爆速にdocker composeを使うためのGitHub ActionをMarketplaceに出した - Qiita
GitHub Actions上で docker compose を爆速に使うための GitHub Action 「Spin-Up Docker Compose」を Marketplace に出しました。 背景 先日、「GitHub Actions上でdocker composeを使ってCIを回すためにうまいことキャッシュする方法」という記事を投稿させていただきました。 ありがたいことにさまざまな方にLGTMをいただくことができ、参考にしていただけたのかなと思っています。 さて、当該の記事への反応を確認しようとはてなブックマークなども閲覧させていただいていたのですが、気になるコメントを見つけました たしかに！いい感じの docker compose 環境を作れたとして、プロジェクトごとにあの分量のymlをコピペして調整して回るのは大変ですよね。 ということで、前回の記事で用意した環境をパッケ
GitHub Actions上でdocker composeを使ってCIを回すためにうまいことキャッシュする方法 - Qiita
docker compose on GitHub Actions 昨今ではDocker（コンテナ）を使った環境整備が主流になってきています。アプリケーションの実行環境自体をコード化できるため、開発環境間の差異や、本番環境の差異を吸収し、アプリケーションの開発に集中することができます。 一方、CIとDockerの相性はなかなかに良くないです。Dockerの肝はイメージやレイヤーのキャッシュにより、初回のダウンロード以降は爆速に使えることですが、環境がある程度リセットされてしまうCI環境で愚直にDockerを動かすコードを書くと数百MB単位のイメージのダウンロード、ビルドが毎回走ることになり、Dockerを準備する処理でCIの処理の大半が使われてしまうこともままあります。 今回はDockerによる環境のカプセル化の恩恵を受けつつ、GitHub Actionsでdocker composeを動か
GitHub ActionsでのPR操作権限はデフォルトでオフになったよ
Run gh pr create -B staging -t Develop -b "" pull request create failed: GraphQL: GitHub Actions is not permitted to create or approve pull requests (createPullRequest) Error: Process completed with exit code 1. 原因 2022/5/3に、GitHub ActionのPR作成とPRのAproveは権限で設定できるようになった。 これの初期値がデフォルトでオフなので、以前まで動いていたGitHubActionsがいきなりコケるようになっていた。 GitHub Actions: Prevent GitHub Actions from creating and approving pull
GitHub Actions から OIDC を使って Google Workspace のドメイン内にのみ共有しているデータにアクセスする
Google Workspace の組織内限定で共有しているスプレッドシートなどのデータに定期的にアクセスして集計スクリプトを回したいときってありますよね。 GAS でやるっていう手もありますが、好きな言語を使えることや、コード管理・デプロイ周りの簡潔さを考えると GitHub Actions に軍配が上がると思います。 GitHub OIDC (OpenID Connect) を使うとGitHub Actions から、サービスアカウントを使ってGoogleのリソースにセキュアにアクセスすることができるようになります。リポジトリに認証情報を持たせる必要もなくなりますし、キーのローテーションも不要になります。 今回この仕組みを使って Google Workspace のドメイン内限定で共有しているドライブ内のファイルやスプレッドシートなどのデータにアクセスする方法をまとめます。 認証には
C#でCustom GitHub Actionを書く | Yucchiy's Note
「Notionでブログを書く」で紹介した通り、notion-to-markdownというアクションの処理はC#で実装しています。 この実装を題材に、C#製のCLIアプリケーションを用いてCustom GitHub Actionを作成する方法について紹介します。 実装に当たってMicrosoftのドキュメント「Tutorial: Create a GitHub Action with .NET」を参考にしています。（特に、C#を動かすためのDockerイメージの作成はほぼそのまま利用しています。） C#でGitHub Actionsの処理を書く まずはC#でアクションの処理を実装します。基本的には、コンソールアプリケーションのテンプレートを用いて実装することになります。 最近のC#ではtop-level statementやglobal usingをサポートしたので、エントリーポイントとなる
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とCypressを使って、テスト自動化環境をゼロから構築する - Qiita
はじめに 本記事は、アジャイル開発手法におけるQAの参考になれば、と作成しました。 開発、QA、また今後、それらに携わっていく方々の即戦的知識になればと思います。 また、本記事で作成したソースコードは下記に公開しています。 https://github.com/EIKINAKAYAMA/cypress-demo そもそもテストって？ システム開発では、システムがリリースされるまで、 作成された開発物に問題がないかを色んなテストでチェックします。 UIテスト ブラックボックステスト 負荷テスト リグレッションテスト 退行テスト 受け入れテスト アドホックテスト etc... 上記は一部を載せていますが、まだまだ沢山あります。 会社や組織によって呼び方が変わったり、テストというよりもテスト手法だったり、同じようで厳密には内容が異なったりと多種多様のテストが存在し、必ずしも全てのテストを実施して
Jenkins ジョブを GitHub Actions 上で動かせるようになりました
概要 Jenkins を GitHub Actions 上で動かすアクションを作りました。 まだ動かない機能もあると思いますが Jenkins から GitHub Actions へ移行する際の選択肢になるといいのかなと思っています。 作ったアクション 設計 CI を移行する際に何が大変かというと異なる言語で書かれた設定ファイルの移植です。 なのでそもそも移植をしなくて済むように Jenkins そのものを Docker Compose で構築して GitHub Actions ランナー上で走らせています。 覚えることを増やさないように独自の機能はほとんど入れていませんので Jenkins の知識があれば大体のことはできるのではないかと思います。 セットアップウィザードをスキップするため認証機能はオフになっています。 操作は Jenkins CLI で行うのが楽です。 Remote Acc
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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発環境のセキュリティおよびCI/CDパイプラインのセキュア化
slack-send - GitHub Marketplace
