回答編集履歴
3
同じマシンのケースを想定していなかったので加筆
test
CHANGED
|
@@ -1,6 +1,11 @@
|
|
|
1
|
-
普通に考えて不可能ですね。
|
|
2
|
-
|
|
1
|
+
このノンベアリポジトリが同じGitマシン内に存在するのであれば、
|
|
2
|
+
post-receiveファイル内でブランチ名を特定した上で、ノンベアリポジトリのディレクトリへ移動して新たなgitコマンドを発行するだけで終わりです。
|
|
3
|
+
参考記事: [Gitのpost-receive Hookでブランチ名などを受け取ったりする](https://songmu.jp/riji/entry/2014-08-07-post-receive-branch.html)
|
|
3
4
|
|
|
5
|
+
もし別マシンだった場合が厄介です。
|
|
6
|
+
post-receiveという実行ファイル1個で別マシンに遠隔操作でGit操作を行わせる事になり、相当困難な作業となります。
|
|
7
|
+
|
|
8
|
+
この場合はWebhookの仕組みを活用したり、メッセージングサーバを立ち上げる事で解決します。
|
|
4
9
|
こういう仕組みを作るのが上手な人なら1,2週間程度でさくっと作ってくれるかもしれませんが、
|
|
5
10
|
エラーのハンドリング等も考えると大変かもしれないですね。
|
|
6
11
|
|
2
ノンベアリポジトリマシン→別マシンに表記を変更
test
CHANGED
|
@@ -12,7 +12,7 @@
|
|
|
12
12
|
|
|
13
13
|
- A: 質問者さんのパソコン
|
|
14
14
|
- B: Gitのサーバ
|
|
15
|
-
- C:
|
|
15
|
+
- C: 追従したい別マシン
|
|
16
16
|
|
|
17
17
|
A -> Bに向けて更新したmasterブランチをpushしました。
|
|
18
18
|
この時、通信はAB間で完結してしまっているので、Cはそれを知る術がありません。
|
|
@@ -46,29 +46,27 @@
|
|
|
46
46
|
---
|
|
47
47
|
|
|
48
48
|
どうやって実行ファイル1個で
|
|
49
|
-
|
|
49
|
+
追従したい別マシンにmasterブランチの更新を知らせてpullをさせるか？
|
|
50
|
-
ノンベアリポジトリマシンにpullをさせるか？
|
|
51
|
-
|
|
52
|
-
今回の障壁となる部分です。
|
|
50
|
+
これが今回の障壁となる部分です。
|
|
53
51
|
|
|
54
52
|
「Gitのサーバ」で実行ファイルを動作させても、
|
|
55
53
|
影響を及ぼせるのは「Gitのサーバ」内だけです。
|
|
56
|
-
そ
|
|
54
|
+
その垣根を勝手に超えて「別マシン」を操作しようなんて、遠隔操作・セキュリティホールに他なりません。
|
|
57
55
|
|
|
58
|
-
|
|
56
|
+
ここは「別マシンで`git pull origin master`を実行するだけ」の仕組みを作って
|
|
59
57
|
その用途だけに使うのが良いでしょう。
|
|
60
|
-
こうしておけば仮に悪意の第三者に知られても「
|
|
58
|
+
こうしておけば仮に悪意の第三者に知られても「別マシンで`git pull origin master`を実行するだけ」という機能を何度も実行されるだけの被害で済みます。
|
|
61
59
|
|
|
62
|
-
-
|
|
60
|
+
- 別マシンでWebサーバを稼働して、特定のURLにアクセスすると「Gitサーバのブランチが更新した」と見なしてpullを試みる
|
|
63
|
-
- PubSub方式のメッセージングサーバを稼働させ、
|
|
61
|
+
- PubSub方式のメッセージングサーバを稼働させ、別マシンはメッセージングサーバにSubscribe側として接続しっぱなしにする。GitサーバからPublishして「Gitサーバのブランチが更新」された事を検知させてpullを試みる
|
|
64
|
-
- Node.jsでWebSocketサーバを開設して、Gitサーバと
|
|
62
|
+
- Node.jsでWebSocketサーバを開設して、Gitサーバと別マシンを接続しっぱなしにする
|
|
65
63
|
|
|
66
64
|
1番目の方法はGitHubでも[Webhook](https://docs.github.com/ja/get-started/customizing-your-github-workflow/exploring-integrations/about-webhooks)という仕組みで提供されています。
|
|
67
65
|
ブランチが更新された等の契機で、機械的にHTTPアクセスを飛ばして通知します。
|
|
68
|
-
受け手となる
|
|
66
|
+
受け手となる別マシンにそのHTTPアクセスを受け取れるWebサーバを構築しておけば良いですね。
|
|
69
67
|
|
|
70
68
|
実現だけなら最も楽だと思います。
|
|
71
|
-
デメリットはGitサーバのpost-receive内に受け手となる
|
|
69
|
+
デメリットはGitサーバのpost-receive内に受け手となる別マシンへHTTPリクエストを飛ばすという情報を覚えさせる必要がある点ですね。
|
|
72
70
|
エンジニアの感覚として、なんで俺がそれを覚える必要があるの？になります。
|
|
73
71
|
|
|
74
72
|
他の方法は別ルートで通知する経路を確保しておいて、
|
1
ちょっとした追記
test
CHANGED
|
@@ -31,7 +31,6 @@
|
|
|
31
31
|
しかし質問文にあった「該当のソースコード」の中身はテキストファイルです。
|
|
32
32
|
実行ファイルじゃないのに実行出来るわけないじゃん。
|
|
33
33
|
|
|
34
|
-
|
|
35
34
|
Linux等でテキストファイルに実行権限を付与して実行した場合、
|
|
36
35
|
ファイルの1行目に書かれている`#!/bin/sh`、これを[シバン](https://e-words.jp/w/%E3%82%B7%E3%83%90%E3%83%B3.html)と呼び、
|
|
37
36
|
書かれている実行ファイルを探して、そいつに読み込ませて実行するという挙動をしてくれます。
|
|
@@ -56,6 +55,10 @@
|
|
|
56
55
|
影響を及ぼせるのは「Gitのサーバ」内だけです。
|
|
57
56
|
それを超えて「ノンベアリポジトリマシン」を操作しようなんて、遠隔操作・セキュリティホールに他なりません。
|
|
58
57
|
|
|
58
|
+
なので用途を狭めた通知する経路を別途用意して
|
|
59
|
+
その用途だけに使うのが良いでしょう。
|
|
60
|
+
こうしておけば仮に悪意の第三者に知られても「ノンベアリポジトリマシンで`git pull origin master`を実行するだけ」という機能を何度も実行される程度の被害で済みます。
|
|
61
|
+
|
|
59
62
|
- ノンベアリポジトリマシンでWebサーバを稼働して、特定のURLにアクセスすると「Gitサーバのブランチが更新した」と見なしてpullを試みる
|
|
60
63
|
- PubSub方式のメッセージングサーバを稼働させ、ノンベアリポジトリマシンはメッセージングサーバにSubscribe側として接続しっぱなしにする。GitサーバからPublishして「Gitサーバのブランチが更新」された事を検知させてpullを試みる
|
|
61
64
|
- Node.jsでWebSocketサーバを開設して、Gitサーバとノンベアリポジトリマシンを接続しっぱなしにする
|