$ sw_vers ProductName: macOS ProductVersion: 15.2 BuildVersion: 24C101 今回の記事のサンプルはSteamDeploySampleになります。 ローカルでのSteamへのアップロードフロー CIでの自動化の前に、まずはローカルでSteamへのアップロードフローを確認します。アップロードフローはSteamworks SDKのドキュメントにまとめられていますが、この記事では簡略化したフローを説明します。 Unity Editorで各種プラットフォーム用のビルドを行う Steamworksでアップロード用SDKをダウンロード（初回のみ） ダウンロードリンク AppID、DepotID、各種ビルドへのパスを記載した設定ファイルを編集 設定ファイルの編集方法 SDKに内包されているスクリプトで認証情報を付与してアップロード Unit
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---
みなさんご存知の通り、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や各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期
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の両
スライド概要 2024/08/22 開催 「GitHub Actionsの最適化どうしてる？ 開発者体験を向上させる運用術」で発表する資料 イベントconnpassページ: https://findy.connpass.com/event/326645/
newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo
はじめに はじめまして、株式会社QualiArtsでバックエンドエンジニアをしている@karamaru_alphaです。 Unityには動画や画像などのアセットに対してプラットフォームごとの変換処理や圧縮処理などを事前に行うアセットバンドルという仕組みがあります。 弊社では従来、このアセットバンドルビルドやUnityアプリビルド環境としてJenkinsを採用してきました。 Jenkinsは手軽にCI/CDプラットフォームを構築できる強力なツールです。 一方で、複数タイトルで運用を行なっていく中でいくつかのデメリットも感じるようになりました。 そこで、本記事ではUnityアセットバンドルビルド環境をJenkinsからGitHub Actionsに移行した取り組みについて紹介します。 はじめに、Unityのビルド環境でなぜJenkinsが採用されてきたのか、その背景を説明します。 次に、弊社で
２０２４-08-19時点の情報 game-ci/unity-buidler@v4を使ってself-hosted runnerでビルドするときに、地味にハマったのでメモ。 ハマリ1. UnityEditorがすでにインストールされているエラーでハマる Run game-ci/unity-builder@v4 Warning: Library folder does not exist. Consider setting up caching to speed up your workflow, if this is not your first build. (node:22372) NOTE: We are formalizing our plans to enter AWS SDK for JavaScript (v2) into maintenance mode in 2023. Pl
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
