GitLabの同じサーバー上のCIランナー？
私は会社でGitLabサーバーをセットアップしており、GitLab CIをそれに追加しています。
このタスクを開始する前に、GitLabとGitLab CIで使用されているのと同じサーバーでランナーを実行することに不利な点があるかどうかを理解したいと思います。
セキュリティ上の懸念があることを読みましたが、私たちはそれを内部でのみ使用しているため、これが問題になることはないと思います。
何か不足していますか？
次の状況を想像してみてください。
内部開発者が会社に危害を加えたいと考えています（上司が妻と寝ているため、給与が足りないと考えているためです。理由は重要ではありません）。実行すると、アプリケーションをテストする代わりに、GitLabリポジトリを検索するユニットテストを実行します。それを消去します。次のコミットでは、驚いたことに、プロジェクトのすべてのソースコードが失われています（ただし、バックアップを実行してテストしましたね）。
または、同じ開発者がリポジトリのバックアップが同じマシン上で構成されていることに気づきました。彼はユニットテストを通じてこの構成を変更し、バックアップに別のリポジトリが含まれるようにし、1か月間（バックアップが保持される時間）待機します。すべてのバックアップが破損したので、サーバーからソースコードを消去する単体テストをコミットできます。
または、インターンがソースコードを競争相手に売りたいと考えています。アクセスを慎重に構成し、彼が仕事に必要なものだけに制限しました。同時に、彼は単体テストを通じてリポジトリ自体に無制限にアクセスでき、完全なダンプを実行できます。
ユニットテストが制限された権限のコンテキストで実行され、テストに必要なディレクトリとファイル以外にアクセスできない場合を除き、CIサーバーとリポジトリを保持するサーバーを混在させることは実際に危険です。
別の問題は、バージョン管理サーバーが高速であることが期待されていることです。同じマシンにCIサーバーがインストールされていると、コミットが遅くなる場合があります。
Gitの「すべてを知っている」中央サーバーがないことを考えると、他のソースコード管理システムの場合と同様に、これは悪くありません。
オフサイトのgitサーバーから別のgitサーバー（テスト済み）へのgitサーバーの自動sykがある場合、小規模な会社ではこの設定について心配する必要はありません。
理想的には、開発者が変更をオフセットサーバーgitサーバーにプッシュしてから、CIサーバーがオフセットサーバーから料金をプルするのを見たいと思います。この方法で、すべてのチェックインが行われるときにオフサイトサーバーがテストされます。
開発者が時間を節約するためにオンサイトサーバーから常にプルした場合、それは問題ではありません。