生成AIを用いると「画像内の物体を移動」「1枚の画像をもとにアニメーションを作成」といった編集作業が可能ですが、物理的にあり得ない結果が出力されることも多々あります。
MiraGeは「Gaussian Splatting」と呼ばれる技術を用いて画像を三次元空間に落とし込むことで、奥行きや他の物体との位置関係などを物理的な破綻なく編集することを可能にします。また、物理エンジンによる「物体の質感の変更」を画像に適用して、「画像内の物体を柔らかくして、曲げる」といった編集も可能です。以下の例では、MiraGeを用いて「三角形の物体を柔らかく曲げつつ移動」「人間の顔の向きや表情を変更」といった編集を施しています。
⇧「線画」の世界線で実現できたら、アニメーションの作画のコストが削減できそうではありますな。
Gitの仕組みをザックリ整理
Gitの仕組み上、
が登場してきて、「2. リモートのGitリポジトリ」に対しては、認証が必要になってきますと。
英語版のWikipediaでの情報だと、
Git (/ɡɪt/) is a distributed version control system that tracks versions of files. It is often used to control source code by programmers who are developing software collaboratively.
Design goals of Git include speed, data integrity, and support for distributed, non-linear workflows — thousands of parallel branches running on different computers.
Git was created for use in the development of the Linux kernel by Linus Torvalds and others developing the kernel.
As with most other distributed version control systems, and unlike most client–server systems, Git maintains a local copy of the entire repository, a.k.a. repo, with history and version-tracking abilities, independent of network access or a central server. A repo is stored on each computer in a standard directory with additional, hidden files to provide version control capabilities.
⇧ とあり、「分散型」が特徴ではありますが、基本的には、「client server model」であると。
「client server model」はというと、
The client–server model is a distributed application structure that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients.
⇧ 上図のような仕組みですと。
当然、「Git」も「client server model」であるので、「client」と「server」が登場することになり、
⇧ というような感じの構成になると。
Some data flows and storage levels in the Git revision control system
⇧ 上図がイメージし易いかと。
で、「server」部分については、
Git server as a service
See also: Comparison of source-code-hosting facilities
There are many offerings of Git repositories as a service. The most popular are GitHub, SourceForge, Bitbucket and GitLab.
⇧ ホスティングサービスを利用することが多いのかなと。
オンプレミス環境に自前でGitリモートサーバーを構築してる環境もあるとは思いますが、昨今は、メジャーなクラウドサービスプロバイダーでもサービスを提供してるかと。
Gitのリモートリポジトリに対しては認証が必要
「Git」は、「client server model」で動作するものとなっている想定なので、
リモートリポジトリは、一般的に ベア（bare）リポジトリ となります。これは、作業ディレクトリをもたない Git リポジトリのことです。 このリポジトリは共同作業の中継地点としてのみ用いられるので、ディスク上にスナップショットをチェックアウトする必要はありません。単に Git のデータがあればそれでよいのです。 端的に言うと、ベアリポジトリとはそのプロジェクトの .git ディレクトリだけで構成されるもののことです。
Git では、データ転送用のプロトコルとして Local、HTTP、Secure Shell (SSH)、Git の四つを使用できます。 ここでは、それぞれがどんなものなのかとどんな場面で使うべきか (使うべきでないか) を説明します。
⇧ マシン間でデータの転送が発生しますと。
で、「Git」のリモートリポジトリに対して、誰でもアクセスして欲しくは無いはずなので、当然のことながら「認証」の仕組みが必要になってきますと。
公式のドキュメントによると、
認証情報の保存
SSH を使ってリモートサーバーと接続しているのなら、パスフレーズなしの鍵を使えます。そうすれば、データ転送を安全に行おうとする際に、ユーザー名やパスワードを入力せずにすみます。 一方、HTTP プロトコルの場合はこうはいきません。接続のたびにユーザー名とパスワードが必要です。 さらに大変になるのが二要素認証が必要なシステムの場合です。パスワードと組み合わせて使うトークンはランダムに生成されており、unpronounceable だからです。
さいわい、Git には認証情報の仕組みがあり、上述のような大変さを軽減してくれます。 標準の仕組みで選択可能なオプションは以下のとおりです。
-
デフォルトでは、なにもキャッシュされません。 接続するたび、ユーザー名とパスワードを尋ねられます。
-
“cache” モードにすると、認証情報が一定の間だけメモリーに記憶されます。 パスワードはディスクには保存されません。15分経つとメモリーから除去されます。
-
“store” モードにすると、認証情報がテキストファイルでディスクに保存されます。有効期限はありません。 ということは、パスワードを変更するまで、認証情報を入力しなくて済むのです。 ただし、パスワードが暗号化なしのテキストファイルでホームディレクトリに保存される、というデメリットがあります。
-
Mac を使っているなら、Git の “osxkeychain” モードが使えます。これを使うと、OS のキーチェーン（システムアカウントと紐づく）に認証情報がキャッシュされます。 このモードでも認証情報がディスクに保存され、有効期限切れもありません。ただし先ほどとは違い、保存内容は暗号化（HTTPS 証明書や Safari の自動入力の暗号化と同じ仕組み）されます。
-
Windows を使っているなら、“wincred” という補助ツールがあります。 “osxkeychain” と同じような仕組み（Windows Credential Store）で、重要な情報を管理します。
⇧ という感じで、「client」側で「認証」に必要な「認証情報」を用意しておく必要がありますと。
2024年10月9日（水）追記：↓ ここから
ちなみに、
⇧ GitHubでは、パスワード認証は非推奨になっており、「PAT（Personal Access Token）」などの「トークンベース認証」を推奨しているようなのですが、
⇧ GitHub上で設定が必要なようなので、トークン更新時は注意が必要と。
2024年10月9日（水）追記：↑ ここまで
GitHub AppのSecretを利用してGitHub Actionで生成したトークンでpushしたかったが...
で、漸く本題。
前に、
⇧「GitHub Apps」という「GitHub」のサービスの話が出てきましたが、アプリケーションとかの処理でGit操作する場合もGitのリモートリポジトリに対して「認証」を実施する必要があり、「認証情報」は、
- 固定値を設定しておき、取得する
- 完全固定
- 定期的に更新
- 都度、生成・取得する
⇧ のようなアプローチで用意する形になると思いますが、昨今は、「二要素認証」などでも使い捨ての「トークン」を発行させていることが多いと思うので、「2. 都度、生成・取得する」のアプローチを取ることが多いのかなと。
で、アプリケーションでGitのリモートリポジトリに対して「認証」する方法としては、
⇧ のようなものがありますと。
⇧ 上記の記事の時に試したのですが、「GitHub App」で生成した「秘密キー（秘密鍵）」を、アプリケーション側で参照できる必要がありますと。
でも、アプリケーションを稼働させるサーバーが1000台ぐらいあり、且つ、サーバーの稼働してる場所がオンプレミス環境で立地的にも散逸している場合、サーバー毎に異なる「秘密キー（秘密鍵）」を用意するのは、辛いですと。
「GitHub App」のドキュメントによると、
⇧「Azure Key Vault」などのサービスを利用することを検討とありますが。
で、ネットの情報を漁っていたところ、
⇧ という「GitHub Action」で「GitHub App」の「インストールアクセストークン」を生成できる仕組みが用意されていることを知りましたと。
この仕組みは、「GitHub App」で生成した「キーペア」の「秘密キー（秘密鍵）」を、「GitHub App」の「Secret」として管理しておき、その「Secret」を「GitHub Action」内で参照して「インストールアクセストークン」を作成する代物らしいですと。
この仕組みであれば、「秘密キー（秘密鍵）」を「GitHub App」の閉じた世界で管理しておけますと。
問題は、「GitHub Action」の仕組みが、「Create GitHub App Token」で生成したトークンを有効活用できるようになっていないっぽいのよね...
公式のドキュメントによると、
⇧ とあり、「ワークフロー トリガー」なるものが、「GitHub Action」のフローをキックするものらしいのですが（つまり、処理の起点）、
⇧ とあり、現状、GitHub Action上で取得した「GitHub App」の「インストールアクセストークン」を利用して、git push することができない模様。
つまり、git pushするには、
「1. GitHub Action外」にならざるを得ない...
「インストールアクセストークン」で「認証」済みになっていないと、「GitHub Action」を外部から実行できないっぽいんですよね...
「ワークフロー トリガー」がネックになっているんよね...
git pushを検知して、git pushの「認証」の部分だけ、「GitHub Action」のフローに委譲することができれば、「GitHub Action」内で生成した「インストールアクセストークン」で「認証」できるとは思うんだが、現状、不可能と。
とりあえず、
⇧ stackoverflowの方法は、結局、「GitHub Action」のトリガーとなるgit pushについての「認証」は、git push実行した側で「認証情報」を用意しておく必要があったので、意味ありませんでしたな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
