- ユースケース
- 名前空間
- グループ内のイシューおよびマージリクエスト
- 新しいグループを作成する
- ユーザーをグループに追加する
- グループへのアクセス権を要求する
- グループのオーナーを変更する
- グループのデフォルトのブランチプロテクションを変更する
- プロジェクトをグループに追加する
- グループの詳細を見る
- グループの活動を見る
- プロジェクトをグループに移管する
- グループでのプロジェクト共有
- グループを他のグループと共有する
- LDAPによるグループメンバー管理
- エピック
- グループセキュリティダッシュボード(ULTIMATE)
- インサイト(ULTIMATE)
- グループの転送
- グループ設定
- ユーザー貢献度分析(STARTER)
- イシュー分析(PREMIUM)
- 依存関係プロキシ(PREMIUM)
グループ
GitLab Groupsを使うと、次のことができます。
- 関連するプロジェクトを一緒に組み立てる。
- メンバーに複数のプロジェクトへのアクセスを一度に許可する。
GitLab Groupsのビデオによる紹介は、GitLab University: Repositories, Projects and Groupsをご覧ください。
また、グループはサブグループにネストさせることができる。
トップナビゲーションの「グループ」>「自分のグループ」をクリックして、自分のグループを見つけることができます。
トップナビゲーションのGroupsドロップダウンは、GitLab 11.1で導入されました。
Groups]ページが表示されます。
- Your groupsを選択した場合、あなたが所属しているすべてのグループ。
- Explore publicgroupsを選択した場合の公開グループの一覧です。
グループ」ページの各グループの一覧は、以下の通りです。
- サブグループをいくつ持っているか
- 何個のプロジェクトが含まれているか。
- グループのメンバー数(親グループから継承されたメンバーは含まれない)。
- グループの知名度
- 十分な権限を持っている場合、グループの設定へのリンクです。
- メンバーであれば、グループから抜けるためのリンク。
ユースケース
グループを作成する理由はさまざまですが、いくつか挙げることができます。
- 関連するプロジェクトを同じ名前空間の下に整理し、最上位のグループにメンバーを追加することで、より少ない手順で複数のプロジェクトや複数のチームメンバーにアクセス権を付与することができます。
- グループを作成し、適切なメンバーを含めることで、イシューやマージリクエストにチーム全員を一度に
@mention
することが容易になります。
例えば、company-teamという
グループを作成し、その中にbackend-team
、frontend-team
、production-teamという
サブグループを作成し、それぞれのチームごとにサブグループを作成することができます。
- イシューから新しい実装を始めるときは、_”
@company-team
, let’s do it!@company-team/backend-team
_you’re good to go!” というコメントを付けます。 - バックエンドのチームがフロントエンドの助けを必要とする場合、_”
@company-team/frontend-team
_could you help us here please?” というコメントを追加します。 - フロントエンドチームが実装を完了すると、”
@company-team/backend-team
, it’s done! Let’s ship it@company-team/production-team
!” とコメントします。
名前空間
GitLabでは、名前空間はユーザー名、グループ名、サブグループ名として使用される一意な名前である。
http://gitlab.example.com/username
http://gitlab.example.com/groupname
http://gitlab.example.com/groupname/subgroup_name
例えば、Alexというユーザーを考えてみましょう。
- Alex は GitLab.com でユーザー名
alex
としてアカウントを作成します。彼らのプロファイルはhttps://gitlab.example.com/alex
でアクセスできるようになります。 - Alex は、自分たちのチームのために
alex-team
という名前のグループを作成します。グループとそのプロジェクトは、https://gitlab.example.com/alex-team
でアクセスできるようになります。 - Alex は
alex-team
にmarketing
というサブグループを作成します。このサブグループとそのプロジェクトはhttps://gitlab.example.com/alex-team/marketing
でアクセスします。
そうすることで
- チームメンバーがAlexに言及する場合は、
@alexを付けて
ください。 - Alexは
@alex-teamで
自分のチームの全員について言及します。 - Alexは
@alex-team/marketingで
マーケティングチームのみについて言及しています。
グループ内のイシューおよびマージリクエスト
イシューおよびマージリクエストは、プロジェクトの一部です。 特定のグループに対して、そのグループ内のすべてのプロジェクトのイシューおよびマージリクエストを、単一のリストビューでまとめて表示することができます。
イシューおよびマージリクエストの一括編集
詳しくは、イシューおよびマージリクエストの一括編集をご覧ください。
新しいグループを作成する
グループ名として使用できない単語の一覧は、予約名を参照してください。
新しいグループを作成するには、次のどちらかを行います。
以下の情報を追加してください。
-
グループ名は、URL に自動的に入力されます。 オプションで変更することもできます。 これは、グループビューに表示される名前です。 名前には、以下のものだけを含めることができます。
- 英数字
- アンダースコア
- ダッシュとドット
- スペース
-
グループURLは、プロジェクトがホストされる名前空間です。 このURLには、以下のものだけを含めることができます。
- 英数字
- アンダースコア
- ダッシュとドット(ダッシュで始まるもの、ドットで終わるものは不可)
- オプションで、このグループが何であるかを他の人に伝えるための簡単な説明を追加することができます。
- オプションで、グループのアバターを選択することができます。
- 視認性のレベルを選択します。
グループの作成について詳しくは、動画「GitLab Namespaces (users, groups and subgroups)」をご覧ください。
ユーザーをグループに追加する
複数のプロジェクトを1つのグループにまとめると、1回の操作でグループ内のすべてのプロジェクトにアクセスできるようになる、という利点があります。
グループのダッシュボードに移動して、「メンバー」をクリックすると、グループにメンバーが追加されます。
また、そのユーザーの有効期限を設定することもできます。 これは、そのユーザーがグループへのアクセス権を失う日です。
2つのプロジェクトがあるグループを考えてみましょう。
- グループメンバー」ページで、新しいユーザーをグループに追加することができるようになりました。
- さて、このユーザーはグループのDeveloperメンバーなので、自動的にそのグループ内のすべてのプロジェクトに Developerアクセスできるようになります。
特定のプロジェクトの既存ユーザーのアクセスレベルを上げるには、そのユーザーをプロジェクトに新規メンバーとして追加し、希望する権限レベルを設定します。
グループへのアクセス権を要求する
グループオーナーになると、メンバー以外からのグループへのアクセス要求を有効または無効にすることができます。 グループ設定に移動し、「ユーザーからのアクセス要求を許可する」をクリックします。
ユーザーとして、グループのメンバーになることを申請することができます(設定が有効な場合)。 メンバーになりたいグループにアクセスし、画面右側の「アクセス申請」ボタンをクリックします。
アクセスを要求されたら
- 最大10人のグループオーナーにメールで通知されます。 メールは、最も最近アクティブになったグループオーナーに送信されます。
- グループのオーナーは、メンバーページであなたのリクエストを承認または拒否することができます。
リクエストが承認される前に気が変わった場合は、「アクセスリクエストの取り下げ」ボタンをクリックするだけです。
グループのオーナーを変更する
グループのオーナーシップとは、メンバーのうち少なくとも1人がオーナー権限を持つことを意味します。 グループには、少なくとも1人のオーナーが必要です。
所有者が1人しかいないグループの所有者を変更することは可能です。 グループの唯一の所有者を変更するには
- 管理者として。
- グループの メンバータブに移動します。
- 別のメンバーに所有者権限を付与する。
- ページを更新すると、元の所有者から所有者権限を削除することができます。
- 現在のグループのオーナーとして。
- グループの メンバータブに移動します。
- 別のメンバーに所有者権限を付与する。
- 新しい所有者にサインインしてもらい、所有者権限を削除してもらう。
グループのデフォルトのブランチプロテクションを変更する
GitLab 12.9で導入されました。
デフォルトでは、すべてのグループは、グローバルレベルで設定されたブランチプロテクションを継承します。
特定のグループに対してこの設定を変更する場合。
- グループの{設定} 設定>一般ページを表示します。
- Permissions, LFS, 2FAのセクションを展開します。
- デフォルトのブランチ保護] ドロップダウンリストで希望のオプションを選択します。
- 変更を保存するをクリックします。
この設定をグローバルに変更するには、デフォルトのブランチプロテクションを参照してください。
注:GitLab Premium以上では、GitLab管理者はグループオーナーがデフォルトのブランチ保護を更新することを無効にすることを選択することができます。
プロジェクトをグループに追加する
新しいプロジェクトをグループに追加するには、2種類の方法があります。
-
グループを選択し、「新規プロジェクト」をクリックします。 その後、プロジェクトの作成を続けます。
-
プロジェクトを作成中に、ドロップダウンメニューから既に作成したグループ・名前空間を選択します。
デフォルトのプロジェクト作成レベル
- GitLab Premium10.5で導入されました。
- 10.7でGitLab Starterに導入されました。
- 11.10でGitLab Coreに移行しました。
デフォルトでは、DevelopersとMaintainersはグループの下でプロジェクトを作成することができます。
特定のグループに対してこの設定を変更する場合。
- グループの「設定」>「一般」ページを表示します。
- Permissions, LFS, 2FAのセクションを展開します。
- Allowed to create projectsドロップダウンリストで、希望するオプションを選択します。
- 変更を保存するをクリックします。
この設定をグローバルに変更するには、「プロジェクト作成のデフォルトの保護」を参照してください。
グループの詳細を見る
グループの詳細ページには、以下のタブがあります。
- サブグループとプロジェクト
- プロジェクトを共有する。
- アーカイブされたプロジェクト。
グループアクティビティ解析の概要
グループの詳細表示では、過去90日間に作成された以下の項目の数も表示されます:(STARTER)。
- マージリクエスト
- イシュー
- メンバー
これらのグループアクティビティ解析は、group_activity_analytics
機能フラグで有効にすることができます。
詳しくは、「グループ活動の表示方法」の項をご覧ください。
グループの活動を見る
グループのアクティビティページには、グループ内で行われた直近のアクションが表示されます。
- プッシュイベント:ブランチへの最近のプッシュ。
- マージイベント:最近行われたマージ。
- イシューイベント: イシューがオープンまたはクローズされました。
- エピックイベント:エピックがオープンまたはクローズした。
- コメント:コメントの公開、非公開。
- チーム:グループに参加または離脱したチームメンバー。
- Wiki:Wikiの作成、削除、更新。
RSSアイコンをクリックすると、すべてのアクティビティフィードをAtomフォーマットでご覧いただけます。
グループのアクティビティページを表示する。
- グループのページに移動します。
- 左のナビゲーションメニューから、「グループ概要」を選択し、「アクティビティ」を選択します。
プロジェクトをグループに移管する
プロジェクトをグループに移管する方法を学びます。
グループでのプロジェクト共有
プロジェクトをグループで共有し、グループメンバー全員が一度にアクセスできるようにすることができます。
また、グループ機能での共有をロックすることも可能です。
グループを他のグループと共有する
GitLab 12.7で導入されました。
プロジェクトをグループで共有する場合と同様に、グループを別のグループで共有することで、グループの直接のメンバーに共有グループへのアクセス権を与えることができます。 これは、継承されたメンバーには有効ではありません。
「Frontend」などのグループを「Engineering」などの別のグループと共有すること。
- 「Frontend」グループページに移動し、左側のナビゲーションメニューから「メンバー」に移動します。
- Invite groupタブを選択します。
- 選択した最大アクセスレベルで「Engineering」を追加します。
- 招待をクリックします。
「Engineering」グループのすべてのメンバーが「Frontend」に追加されたことになります。
LDAPによるグループメンバー管理
グループ同期では、LDAP グループを GitLab グループにマッピングすることができます。 これにより、グループごとのユーザー管理をより細かく制御できます。 グループ同期を設定するには、group_base
DN('OU=Global Groups,OU=GitLab INT,DC=GitLab,DC=org'
) を編集します。 このOUには GitLab グループと関連付けられるすべてのグループ が含まれています。
グループリンクはCNまたはフィルタを使用して作成できます。 これらのグループリンクはグループ設定 -> LDAP同期ページで作成されます。 リンクを設定した後、ユーザーがGitLabグループと同期するために1時間以上かかる場合があります。
LDAPおよびグループシンクの管理の詳細については、LDAPのメインドキュメントを参照してください。
注:LDAP同期を追加した際に、LDAPユーザーがグループメンバーであり、LDAPグループに所属していない場合は、グループから削除されます。
CNによるグループリンクの作成(STARTERのみ)
CNでグループリンクを作成する場合。
- リンク先のLDAPサーバーを選択します。
-
同期方法として、「
LDAPグループcn
」を選択します。 -
LDAP Group cntext input boxに、グループのCNを入力します。 設定された
group_baseに
一致するCNのドロップダウンメニューが表示されます。 この一覧から、CNを選択します。 - LDAPアクセス」セクションで、このグループでシンクされるユーザーの権限レベルを選択します。
- このグループリンクを保存するには、[
Add Synchronization
]ボタンをクリックします。
フィルターによるグループリンクの作成(PREMIUMのみ)
フィルターでグループリンクを作成する場合。
- リンク先のLDAPサーバーを選択します。
-
同期方法として、
LDAPユーザーフィルタを
選択します。 - LDAP User filterボックスにフィルターを入力します。ユーザーフィルターに関するドキュメントに従います。
- LDAPアクセス」セクションで、このグループでシンクされるユーザーの権限レベルを選択します。
- このグループリンクを保存するには、[
Add Synchronization
]ボタンをクリックします。
ユーザー権限のオーバーライド(STARTERのみ)
GitLabv8.15から、LDAPユーザーのパーミッションをadminユーザーが手動で上書きできるようになりました。 ユーザーのパーミッションを上書きするには、次のようにします。
- グループの「メンバー」ページにアクセスします。
- 編集するユーザーの行にある鉛筆のアイコンを選択します。
- オレンジ色の「
アクセス権の変更
」ボタンを選択します。
これで、Membersページからユーザーの権限を編集できるようになります。
エピック
GitLab Ultimate10.2 で導入されました。
エピックは、プロジェクトやマイルストーンをまたいで、テーマを共有するイシューのグループを追跡することで、より効率的かつ少ない労力でプロジェクトのポートフォリオを管理することができます。
グループセキュリティダッシュボード(ULTIMATE)
グループとそのサブグループに属するすべてのプロジェクトの脆弱性の概要を把握することができます。
インサイト(ULTIMATE)
GitLab Ultimate12.0から導入されました。
グループやプロジェクトにとって重要なインサイトを設定することで、ユーザーは以下のようなデータを探索することができます。
- トリアージ衛生管理
- 一定期間内に作成/クローズされたイシュー
- マージリクエストがマージされるまでの平均時間
- もっと見る
グループの転送
GitLab 10.5から、以下の方法でグループを転送できるようになりました。
- サブグループを新しい親グループに転送する。
- トップレベルのグループを目的のグループに転送して、サブグループに変換します。
- サブグループを現在のグループから移し、トップレベルのグループに変換する。
グループ転送を行う場合は、ご注意ください。
- グループの親を変更すると、意図しない副作用が発生することがあります。リポジトリパスを変更したときのリダイレクトを参照してください。
- グループの転送は、自分が管理しているグループに対してのみ可能です。
- 新しい場所を指すように、ローカルリポジトリを更新する必要があります。
- 直接の親グループの可視性がグループの現在の可視性より低い場合、サブグループとプロジェクトの可視性レベルは、新しい親グループの可視性に合わせて変更されます。
- グループのオーナーが継承されたメンバーシップのみを持つ場合、グループにはオーナーがいません。 この場合、グループを譲渡したユーザーがグループのオーナーとなります。
グループ設定
グループを作成した後、グループのダッシュボードに移動し、「設定」をクリックすると、グループの設定を管理することができます。
一般設定
グループ作成時に設定した内容を編集できるほか、グループの詳細な設定にアクセスすることができます。
グループのパスを変更する
グループのパスを変更すると、意図しない副作用が発生する可能性があります。 先に進む前に、リダイレクトがどのように動作するかを読んでください。
他のグループやユーザーが使用できるようにパスを空ける場合、名前とパスの両方が一意である必要があるため、グループの名前も変更する必要があるかもしれません。
グループパスを変更する場合。
- グループの「設定」>「一般」ページに移動します。
- パス、転送、削除のセクションを展開します。
- グループパスの変更]に新しい名前を入力します。
- グループパスの変更]をクリックします。
注意:現在、Container Registryタグを持つプロジェクトが含まれる名前空間は、プロジェクトを移動できないため、名前を変更することはできません。
ヒント:元の名前空間の所有権を保持し、URLリダイレクトを保護したい場合、グループのパスを変更したりユーザー名を変更したりする代わりに、新しいグループを作成してそこにプロジェクトを転送することができます。
グループを削除する
グループとその内容を削除するには
- グループの{設定} 設定>一般ページに移動します。
- パス、転送、削除のセクションを展開します。
- グループの削除セクションで、「グループの削除」ボタンをクリックします。
- と聞かれたら、動作を確認する。
このアクションはどちらかです。
- グループを削除し、そのグループ内のすべてのプロジェクトを削除するバックグラウンドジョブをキューに入れます。
- GitLab 12.8以降、プレミアムまたはシルバー以上の階層では、グループを削除するようにマークします。 デフォルトでは7日後に削除されますが、インスタンスの設定で変更することが可能です。
グループの復元(PREMIUM)
GitLab 12.8で導入されました。
削除マークがついているグループを復元する場合。
- グループの{設定} 設定>一般ページに移動します。
- パス、転送、削除のセクションを展開します。
- Restore groupセクションで、Restore groupボタンをクリックします。
グループメンバーへの2FAの適用
グループメンバー全員に2ファクタ認証(2FA)を適用することで、グループにセキュリティレイヤーを追加することができます。
グループロックで共有
グループ内のプロジェクトが他のグループと共有できないようにすることで、プロジェクトのアクセス制御をより厳密に行うことができます。
例えば、あるプロジェクトで2つの異なるチーム(グループAとグループB)が一緒に作業しているとします。グループロックを使った共有では、グループ内のプロジェクトが他のグループと共有されるのを防ぎ、正しいグループメンバーのみがそれらのプロジェクトにアクセスできることを保証します。
この機能を有効にするには、グループ設定ページに移動し、「グループロックで共有」と「グループを保存」を選択します。
メンバーロック(STARTER)
メンバーロックは、グループオーナーがグループ内のすべてのプロジェクトに対して新しいプロジェクトメンバーの加入を防ぐことができ、プロジェクトメンバーをより厳密に管理することができます。
たとえば、監査イベントのためにグループをロックする場合、メンバーロックを有効にすると、その監査中にプロジェクトのメンバーシップが変更されないことが保証されます。
この機能を有効にするには
- グループの[設定] > [一般]ページに移動します。
- Permissions, LFS, 2FA] セクションを展開し、[Member lock] を選択します。
- 変更を保存するをクリックします。
これにより、これまでプロジェクトメンバーの操作権限を持っていたすべてのユーザーのオプションが無効になり、新しいユーザーを追加することができなくなります。 また、APIを通じて新しいユーザーをプロジェクトに追加するリクエストは一切行えなくなります。
IPアクセス制限(PREMIUM)
- GitLab Ultimate および Gold12.0 で導入されました。
- 13.1でGitLab PremiumとSilverに移行しました。
特定のリソースに組織内の人だけがアクセスできるようにするために、IPアドレスでグループとその下にあるプロジェクト、課題などへのアクセスを制限するオプションがあります。 これは、インスタンス全体へのアクセスを遮断しない一方で、特定のコンテンツが敷地外に出ないようにするために役立ちます。
グループ設定に、カンマ区切りのCIDR表記で1つ以上の許可IPサブネットを追加すると、異なるIPアドレスから来た人は、制限されたコンテンツにアクセスできなくなります。
現在、制限を適用しているのは
- UIです。
- GitLab 12.3より、APIアクセス。
- GitLab 12.4から、SSH経由のGitアクションが可能になりました。
偶発的なロックアウトを避けるため、管理者とグループオーナーはIP制限に関係なくグループにアクセスすることができます。
ドメイン制限を許可する(PREMIUM)
- GitLab PremiumとSilver12.2で導入されました。
- GitLab 13.1で導入された複数のメールドメインを指定することができるようになりました。
特定のドメインの電子メールアドレスを持つユーザーのみをグループに追加することを許可することで、グループへのアクセスを制限することができます。
許可したいメールドメインを追加し、異なるドメインのメールを持つユーザーは、このグループに追加することができません。
ドメインによっては、制限できないものもあります。 これらは、最も一般的な公開メールのドメインです。
gmail.com
yahoo.com
hotmail.com
aol.com
msn.com
hotmail.co.uk
hotmail.fr
live.com
outlook.com
icloud.com
この機能を有効にするには
- グループの[設定] > [一般]ページに移動します。
- Permissions, LFS, 2FA] セクションを展開し、[Restrict membership by email] フィールドにドメイン名を入力します。
- 変更を保存するをクリックします。
これにより、この時点からグループに追加されたすべての新しいユーザーに対してドメインチェックが有効になります。
グループファイルのテンプレート(PREMIUM)
グループファイルテンプレートは、共通のファイルタイプ用のテンプレートセットをグループ内のすべてのプロジェクトで共有することができます。 これはインスタンステンプレートリポジトリ機能に類似しており、選択したプロジェクトはそのページで説明されているのと同じ命名規則に従っている必要があります。
テンプレートソースとして選択できるのは、グループ内のプロジェクトのみです。 これには、グループと共有しているプロジェクトは含まれますが、設定中のグループのサブグループや親グループのプロジェクトは含まれません。
この機能は、サブグループと直接の親グループの両方に対して設定できます。 サブグループのプロジェクトは、そのサブグループと直接の親グループのテンプレートにアクセスすることができます。
この機能を有効にするには、グループ設定ページに移動し、テンプレートセクションを展開し、テンプレートリポジトリとして機能するプロジェクトを選択し、グループを保存します。
グループレベルのプロジェクトテンプレート(PREMIUM)
グループをテンプレートソースとして設定し、グループレベルでプロジェクトテンプレートを定義します。グループレベルのプロジェクトテンプレートについてはこちらをご覧ください。
メール通知を無効にする
GitLab 12.2で導入されました。
グループ(サブグループとプロジェクトを含む)に関連するすべての電子メール通知を無効にすることができます。
この機能を有効にするには
- グループの[設定] > [一般]ページに移動します。
- Permissions, LFS, 2FA] セクションを展開し、[Disable email notifications] を選択します。
- 変更を保存するをクリックします。
グループメンテーションの無効化
GitLab 12.6 で導入されました。
ユーザーが会話に追加され、そのユーザーがメンバーであるグループについて誰かが言及したときに通知を受けるのを防ぐことができます。
無効化されたメンションがあるグループは、オートコンプリートドロップダウンでそれに応じて可視化されます。
特にユーザー数の多いグループには有効です。
この機能を有効にするには
- グループの[設定] > [一般]ページに移動します。
- Permissions, LFS, 2FA] セクションを展開し、[Disable group mentions] を選択します。
- 変更を保存するをクリックします。
詳細設定
- プロジェクト:グループ内のすべてのプロジェクトの表示、各プロジェクトへのメンバーの追加、各プロジェクトの設定へのアクセス、プロジェクトの削除をすべて同じ画面から行うことができます。
- Webhooks:グループのWebhooksを設定します。
- Kubernetesクラスタとの連携:GitLabグループとKubernetesクラスタを連携させることができます。
- 監査イベント:グループの監査イベントを表示します(STARTERのみ)。
- パイプラインクォータ:グループのパイプラインクォータを把握する。
ストレージ使用量のクォータ(STARTER)
GitLab Starter12.0から導入されました。
グループオーナーは、グループページの設定リストにある使用量割り当てページのストレージタブで、サブグループを含むグループ内のすべてのプロジェクトのストレージ使用量の集計を確認することができます。
ストレージの使用量の合計は、その値に影響を与える関連イベント(コミットプッシュなど)が発生した場合に更新されます。 パフォーマンス上の理由から、最大1時間30分まで更新を遅らせることがあります。
ネームスペースがストレージの総使用量としてN/A
と表示された場合、そのネームスペース内の任意のプロジェクトにコミットをプッシュすることで再計算をトリガーすることができます。
グループプッシュルール(STARTER)
GitLab Starter12.8 で導入されました。
グループプッシュルールでは、グループの管理者が、特定のグループ内で新しく作成されたプロジェクトに対してプッシュルールを設定することができます。
グループのプッシュルールを設定するには、グループのサイドバーから{push-rules}に移動します。
設定すると、新しいサブグループには、どちらかに基づいてプッシュルールが設定されます。
- プッシュルールが定義されている最も近い親グループ。
- 親グループにプッシュルールが定義されていない場合、インスタンスレベルで設定されるプッシュルール。
機能を有効にする
この機能は、デフォルトでは:group_push_rules
機能フラグが無効になっています。 特定のグループに対して有効にするには、機能フラグAPI エンドポイントを使用するか、Rails コンソールにアクセスできる GitLab 管理者が実行することで可能です。
Feature.enable(:group_push_rules)
最大アーティファクトサイズ(COREのみ)
グループの最大アーティファクトサイズの設定については、「最大アーティファクトサイズ」を参照してください。
ユーザー貢献度分析(STARTER)
GitLab Contribution Analyticsを使えば、グループのメンバーが行った貢献(プッシュ、マージリクエスト、課題)の概要を把握することができます。
イシュー分析(PREMIUM)
GitLab Issues Analyticsでは、グループ内で毎月作成されるイシューの数を棒グラフで確認することができます。
依存関係プロキシ(PREMIUM)
GitLabを上流のDockerイメージの依存関係プロキシとして使用します。