GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される 大事なことなので、見出しでも同じことを書いてしまいました。 何を言っているんだという感じですが、とにかくそういうことらしいです。 厳密には最後にワークフローにコミットしたユーザーが組織から削除されると、無効になるようです。 GitHub Actionsの定期実行でPR作成を自動化*1している会社もそれなりにあるかと思うのですが、その場合はそれらが全部停まります。 さらに、1度無効化されてしまった場合はcron式を変更しないといけないというのも罠ポイントですね。 最後にワークフローの Cron スケジュールにコミットしたユーザーが組織から削除されると、スケジュールされたワークフローは無効になります。 リポジトリへの write アクセス許可を持つユーザーが Cron スケ
毎回開発版アプリを配布する際に、手動で対応内容を記入するのは手間がかかります。 そこで、CIで自動配布する際に、リリースノートも自動的に取得できるようにします。 リリースノートの内容は、対象ブランチにマージされた各PRのタイトルです。 権限設定 GitHubのAPIを使用してリリースノートを取得します。まずは、APIリクエスト用のトークンを作成します。 対象リポジトリに権限を持つアカウントであれば、トークンを作成可能です。以下の画面で「repo」をチェックし、トークンの有効期限を設定します。 設定が完了したら、「Generate token」ボタンをクリックし、生成されたトークンを保存します。 jqでPRタイトルを取得 jqの使い方は公式サイトで確認できます。 プロジェクト内でtest_get_pr_title.shを作成し、以下のコードを入力します。 #!/bin/sh # 外部から対象
はじめに 組織のプライベートリポジトリに、PRが作られるたびGitHub Actionsを用いてreviewdogにESLintのエラーをコメントさせようと思いました。 しかし、reviewdogのREADME.mdに書いてあるようにデフォルトのGitHub Tokenを使っても、そのTokenにはPRへコメントする権限がなかったです（故に、コメントできなかった。。）。 そこで、 GitHub Apps を使用する方法を採用することにしました！ ただし、自分は組織の管理者ではないので、 組織にGitHub Appsを作ることもインストールすることもできません。 あーだこーだやって最終的にはできましたが、それなりにつまづいたので、つまづきポイントと共に記事にして供養します！ 前提知識 GitHub Apps 公式ドキュメントより「データへのアクセスについてより細やかな権限を提供することから、
やりたいこと GraphQLのスキーマファイルの更新があった際に別のリポジトリにファイルを同期させたい。 結論 以下のワークフローファイルでファイルのコピー・別リポジトリへのブランチの作成・コミット・プッシュ・PRの作成ができます。 name: copy GraphQL schema to another-repo on: push: branches: - main paths: - "app/graphql/schema.graphql" workflow_dispatch: jobs: copy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Generate token id: generate_token uses: tibdex/github-app-t
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 一部書きかけになってしまったので後ほど追記します🙇♂️ はじめに これまでJenkinsを使ってたけどGitHub ActionsでUnityのAndroid/iOSビルドしたい！ でも... GitHubホステッドランナーは使いたくない コストがかかる スペックが固定 (Androidビルドがなぜかうまくいかない) (途中でマシンとの通信が途絶える...) act は使いたくない（辛い過去がある） ジョブの実行後にマシンの状態を引き継ぎたくない 手元にAppleシリコンMacがある ということで、 GitHub Actionsセル
はじめに こんにちは！Hamee株式会社の tatsuo48 です。 GitHub ActionsにはデフォルトでGITHUB_TOKENというシークレットが存在しており、環境変数にセットして利用することで、Actionsがトリガーされたリポジトリに対する操作が可能です。 GITHUB_TOKENシークレットについて これはこれで便利なんですが、特定の条件のときに少し問題があります。 CIの中で別リポジトリを使いたいときどうする問題 上記の通り、GITHUB_TOKENでは権限の範囲がActionsがトリガーされたリポジトリに制限されます。よって以下のようなユースケースには適しません。 CIの中で別のプライベートリポジトリを参照したい Terraformのプライベートモジュールとか こういった場合、マシンユーザという人に紐付かないユーザを作り、そのユーザの個人アクセストークンが使われたりす
こんにちは。 私は普段はメーカーでUIデザインを担当しています。 この記事はGithub ActionsもGithub Appsも使ったこともない、汚いおじさんデザイナーが備忘録として書いているメモです。 間違っていたり、もっといい方法があったりするかもしれません。 何がしたいのか 社内には複数のアプリ(プロダクト)があり日々開発が進んでいます。 こちらの記事でも書きましたが、社内のアプリにアイコンや、色指定など共通部分が多くあり、現状プロダクト毎に管理しているので、更新性がイマイチです。 そこで、このデザイントークンと呼ばれるような情報をFigmaからGithubに連携してなるべく自動化したいと思い賢い人達の情報を見ながら試行錯誤しています。 Figma内のアイコンをGithubに対してプルリクエストを出すところまではできましが、次に以下の問題にぶち当たりました。 ◎問題 プロダクト毎に
TLDR; The cache backend service has been rewritten from the ground up for improved performance and reliability. The @actions/cache package now integrates with the new cache service (v2) APIs. The new service will gradually roll out as of February 1st, 2025. The legacy service will also be sunset on the same date. Changes in this release are fully backward compatible. All previous versions of this
概要 Unityのアプリはアセットサイズが膨らみがちです。そのため冪等性や保守コストはある程度諦めてJenkinsを使ってビルドする、ということも多かったです。 さて、そんな人が「最近Jenkinsのプラグインも保守大変だし、流行りのGithub Actionsっていうのに移行しようかな…でもクラウドのMacは高そうだし手元のMacをビルドマシンにしたいな…」 みたいなことを考えた時に知っておくと良さそうなことをまとめておきます。 無限にお金がある場合はGithub Hosting RunnerのLarge Runnerをぶん回した方が考えるコストが減るとは思います。 この投稿はKDDIテクノロジーアドベントカレンダーの12/8分の記事です。 他の記事はこちらです。 https://qiita.com/advent-calendar/2024/kddi-technology 先行事例調査
名前やURLなどは適当に入れてもらっていいです。 WebhookのActiveは、チェックを外します。 Repository permissionsのContentsのアクセスをRead以上にします。 Create Github Appをクリックします。 インストール 作成したら、Generate a private keyをクリックして、keyを保存してください。 private keyとApp IDを使用します。 Install Appでインストールします。 インストールするとリポジトリを選択できますので、ファイル操作を許可したいリポジトリを選択します。 操作したいリポジトリのsecretsにAPP_IDとPRIVATE_KEYを登録します。 PRIVATE_KEYは、-----BEGIN RSA PRIVATE KEY-----と-----END RSA PRIVATE KEY---
業務で開発しているゲームの広告SDKアップデートに伴い、Gradleをv6.7.1以降にアップグレードする必要がでてきました。 ローカル環境でビルドする分には大した作業ではないですが、Unity Cloud Buildでビルドする方法についてはまとまった情報がなかったため、備忘録もかねてこちらでまとめました。 手順としては [ 1 ] pre-build scriptを作成する [ 2 ] Pre-Export methodを作成する [ 3 ] Unity Build Automationの Configurationを編集する という流れになります。順に解説していきます。 1. pre-build script を作成する Unity プロジェクトのルート直下に .ci というディレクトリを作成し、その中に pre-build-script.sh (ディレクトリ、ファイル名は自身が分か
みなさんご存知の通り、GitHub Actions のmacOS ランナーは高いため、自分でビルド用のマシンを用意して self-hosted runner として利用することは多々あると思います。 そういった環境で署名済みの ipa を export したい場合、Distribution 証明書と Provisioning Profile を GitHub Action の Secret に保存し、ワークフロー内でデコードして利用することが一般的です。 そんな時このエラーに遭遇したので、その解決方法を共有します。 Warning: unable to build chain to self-signed root for signer "Apple Distribution: Your Team (XXXXXXXXXX)" なぜこれで解決するのか GitHub Actions への証明書
Unityプロジェクトの開発において、継続的インテグレーション（CI）と継続的デリバリー（CD）は品質向上と迅速なデプロイに不可欠です。本記事では、GitHub Actionsを使用してUnity Cloud Buildを自動化し、Pull Request（PR）のコメントからビルドをトリガーする方法について詳しく解説します。これにより、開発チームは手動でのビルド操作を減らし、効率的なワークフローを実現できます。 シナリオの概要 以下のGitHub Actionsワークフローは、PRに特定のコメント（例：/build）が追加された際に自動的にUnity Cloud Buildをトリガーします。 本ワークフローを利用する前に、Unity Cloud Buildで必要なビルドターゲットの追加など、事前準備が完了している必要があります。 ビルドのステータスはDiscordのチャンネルに通知される
本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった！」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人 GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人 本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。 GitHub Actionsの設計指針 GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期
XcodeCloudのテスト実行時間を20%削減することができたので、当時の状況や対応策についてまとめてます。 前提 iOSプロジェクトの構成はSwift Package Manager + Cocoapodsで管理(Swift Package Managerを活用したクラシルリワードのiOSアプリ構成) CI/CDはXcodeCloudを利用 課題 CIの実行時間がプロジェクトの規模にしては遅い 2024/10時点では1回のテスト実行に24分の時間がかかっていました トランクベース開発で細かくPRを作成しているため、早くCIの結果を確認したいものの、待ち時間が長くなり開発フローに支障が出ていました e.g. CI完了直前にテストがこけて再修正、軽微な修正だがCI実行完了まで待たないといけないなど また、XcodeCloudの実行時間上限も考慮する必要があり、無駄な実行を極力避けたい状況で
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 STYLYは多数のハードウェアに対応したXRのサービスです。STYLYでは、UnityクライアントのソースコードにPRが作成されるたびに、Github Actionsでworkflowを起動し、それによりUnityBuildAutomationへプロジェクト登録を行い、ビルド・テスト環境を構築しています。今、構築し運用しているシステムでは、9種のプラットフォームにおいて、ビルド・テストする環境が整備されています。また、主要なプラットフォームであるスマホ版STYLYにおいては、AirTest+PocoによるAndroid,iOSの両
目次 JetBrains Qodanaは静的解析をCI/CDシステムのチームレビューに拡張するコード品質プラットフォームです。 その強みの 1 つは、特にコード レビュー標準と品質ゲートの設定に関して、チームがより効果的に共同作業できるようになることです。このプロセスにより、チーム全員がこれらの標準をより厳密に遵守することも促進されます。 私たちの VR Unity チームは、社内の Unity プロジェクトである Archipelago で Qodana を試してみることにしました。Archipelago は、売上を山の形で視覚化する仮想現実アプリです。Qodana は、すべての Rider の Unity 検査 を CI 分析に取り入れているため、チーム全体でコードをレビューでき、VSCode および JetBrains ユーザーにとって最も魅力的な Unity ツールの 1 つとなっ
スライド概要 2024/08/22 開催 「GitHub Actionsの最適化どうしてる？ 開発者体験を向上させる運用術」で発表する資料 イベントconnpassページ: https://findy.connpass.com/event/326645/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
