VladPolskiy/gitlab-foss
1
0
Fork 0
mirror of https://gitlab.com/gitlab-org/gitlab-foss.git synced 2025-07-23 00:47:51 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

Add latest changes from gitlab-org/gitlab@master

Browse Source
This commit is contained in:
GitLab Bot
2025-06-18 15:09:56 +00:00
parent eccb332270
commit bc4d5c2595
7 changed files with 122 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
doc/administration/auditor_users.md
View File

@ -12,24 +12,25 @@ title: Auditor users
{{< /details >}}
Users with auditor access have read-only access to all groups, projects, and other resources except:
Auditor users have read-only access to all groups, projects, and other resources in the instance.
- The [**Admin** area](admin_area.md).
- Project and group settings.
Auditor users:
For more information, see [Auditor user permissions and restrictions](#auditor-user-permissions-and-restrictions)
section.
- Have read-only access to all groups and projects.
- Due to a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/542815), users must have at least the Reporter role to perform read-only tasks.
- Can have additional [permissions](../user/permissions.md) to groups and projects based on their assigned role.
- Can create groups, projects, or snippets in their personal namespace.
- Cannot view the Admin area or perform any administration actions.
- Cannot access group or projects settings.
- Cannot view job logs when [debug logging](../ci/variables/variables_troubleshooting.md#enable-debug-logging) is enabled.
Situations where auditor access for users could be helpful include:
Auditor users are sometimes used in situations where:
- Your compliance department wants to run tests against the entire GitLab base
to ensure users are complying with password, credit card, and other sensitive
data policies. You can achieve this with auditor access without giving the compliance department
user administration rights or adding them to all projects.
- If particular users need visibility or access to most of all projects in
your GitLab instance, instead of manually adding the user to all projects,
you can create an account with auditor access and then share the credentials
with those users to which you want to grant access.
- An organization needs to test security policy compliance across an entire GitLab instance.
An auditor user can do this without being added to every project or given administrator access.
- A specific user needs to view a large number of projects in the GitLab instance. Instead of
manually adding the user to every project, you can create an auditor user that can access
every project automatically.
{{< alert type="note" >}}
@ -37,45 +38,18 @@ An auditor user counts as a billable user and consumes a license seat.
{{< /alert >}}
## Add a user with auditor access
## Create an auditor user
To create a new user account with auditor access (or change an existing user):
To create a user account with auditor access:
To create a new auditor user:
1. On the left sidebar, at the bottom, select **Admin**.
1. Select **Overview > Users**.
1. Create a new user or edit an existing one. Set **Access Level** to **Auditor**.
1. If you created a user, select **Create user**. For an existing user, select **Save changes**.
1. Select **New user**.
1. In the **Account** section, enter the required account information.
1. For **User type**, select **Auditor**.
1. Select **Create user**.
To revoke auditor access from a user, follow these steps but set **Access Level** to **Regular**.
You can also create auditor users with:
You can also give users auditor access using [SAML groups](../integration/saml.md#auditor-groups).
## Auditor user permissions and restrictions
Auditor access is not a read-only version of administrator access because it doesn't permit access to the **Admin** area.
For access to their own resources and resources within a group or project where they are a member,
users with auditor access have the same [permissions](../user/permissions.md) as regular users.
If you are signed in with auditor access, you:
- Have full access to the projects and groups you own.
- Have read-only access to the projects and groups you are not a member of. Because of a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/542815) this is not supported. Users must have at least the Reporter role for read-only tasks.
- Have [permissions](../user/permissions.md) based on your role to projects and groups you are a member of. For example, if you have the Developer role,
you can push commits or comment on issues.
- Can access the same resources using the GitLab UI or API.
- Can't view the **Admin** area, or perform any administration actions.
- Can't view job logs when [debug logging](../ci/variables/variables_troubleshooting.md#enable-debug-logging) is enabled.
## Maintain auditor users using API
{{< history >}}
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/366404) in GitLab 15.3.
{{< /history >}}
Administrators can use the GitLab API to [create](../api/users.md#create-a-user) and
[modify](../api/users.md#modify-a-user) auditor users.
- [SAML groups](../integration/saml.md#auditor-groups).
- The [users API](../api/users.md).

52
doc/administration/external_users.md
View File

@ -12,48 +12,46 @@ title: External users
{{< /details >}}
In cases where it is desired that a user has access only to some internal or
private projects, there is the option of creating **External Users**. This
feature may be useful when for example a contractor is working on a given
project and should only have access to that project.
External users have limited access to internal or private groups and projects in the instance. Unlike regular users, external users must be explicitly added to a group or project. However, like regular users, external users are assigned a member role and gain all the associated [permissions](../user/permissions.md#project-members-permissions).
External users:
- Cannot create project, groups, and snippets in their personal namespaces.
- Can only create projects (including forks), subgroups, and snippets within top-level groups to which they are explicitly granted access.
- Can access public groups and public projects.
- Can only access projects and groups to which they are explicitly granted access. External users cannot access internal or private projects or groups that they are not granted access to.
- Can only access public snippets.
- Can access public groups, projects, and snippets.
- Can access internal or private groups and projects where they are members.
- Can create subgroups, projects, and snippets in any top-level groups where they are members.
- Cannot create groups, projects, or snippets in their personal namespace.
Access can be granted by adding the user as member to the project or group.
Like usual users, they receive a role for the project or group with all
the abilities that are mentioned in the [permissions table](../user/permissions.md#project-members-permissions).
For example, if an external user is added as Guest, and your project is internal or
private, they do not have access to the code; you need to grant the external
user access at the Reporter level or above if you want them to have access to the code. You should
always take into account the
[project's visibility](../user/public_access.md#change-project-visibility) and [permissions settings](../user/project/settings/_index.md#configure-project-features-and-permissions)
as well as the permission level of the user.
External users are commonly created when a user outside an organization needs access to only a
specific project. When assigning a role to an external user, you should be aware of the
[project visibility](../user/public_access.md#change-project-visibility) and
[permissions](../user/project/settings/_index.md#configure-project-features-and-permissions)
associated with the role. For example, if an external user is assigned the Guest role for a
private project, they cannot access the code.
{{< alert type="note" >}}
External users still count towards a license seat, unless the user has the [Guest role](../subscriptions/self_managed/_index.md#free-guest-users) in the Ultimate tier.
An external user counts as a billable user and consumes a license seat.
{{< /alert >}}
An administrator can flag a user as external by either of the following methods:
## Create an external user
- [Through the API](../api/users.md#modify-a-user).
- Using the GitLab UI:
1. On the left sidebar, at the bottom, select **Admin**.
1. On the left sidebar, select **Overview > Users** to create a new user or edit an existing one.
There, you can find the option to flag the user as external.
To create a new external user:
Additionally, users can be set as external users using:
1. On the left sidebar, at the bottom, select **Admin**.
1. Select **Overview > Users**.
1. Select **New user**.
1. In the **Account** section, enter the required account information.
1. Optional. In the **Access** section, configure any project limits or user type settings.
1. Select the **External** checkbox.
1. Select **Create user**.
You can also create external users with:
- [SAML groups](../integration/saml.md#external-groups).
- [LDAP groups](auth/ldap/ldap_synchronization.md#external-groups).
- the [External providers list](../integration/omniauth.md#create-an-external-providers-list).
- The [External providers list](../integration/omniauth.md#create-an-external-providers-list).
- The [users API](../api/users.md).
## Make new users external by default

52
doc/administration/guest_users.md
View File

@ -12,21 +12,32 @@ title: Guest users
{{< /details >}}
Users assigned the Guest role have limited access and capabilities compared to other user roles. Their permissions are restricted and are designed to provide basic visibility and interaction without compromising sensitive project data. For more information, see [Roles and permissions](../user/permissions.md).
Users with the Guest role have limited access and capabilities compared to other user roles. Their [permissions](../user/permissions.md) are restricted and designed to provide only basic visibility and interaction without compromising sensitive project data.
In GitLab Free and Premium, Guest users count towards the license seat usage.
Users with the Guest role:
## Unlimited seat usage
- Can access public groups and projects.
- Can view project plans, blockers, and progress indicators.
- Can create and link new project work items.
- Can view high-level project information such as:
- Analytics
- Incident reports
- Issues and epics
- Licenses
- Cannot create projects, groups, and snippets in their personal namespaces.
- Cannot modify existing data they didn't create.
- Cannot view code in projects.
{{< details >}}
## Seat usage
- Tier: Ultimate
- In GitLab Free and Premium, users with the Guest role count as a billable user and consume a license seat.
- In GitLab Ultimate, users with the Guest role do not count as a billable user or consume a license seat.
{{< /details >}}
{{< alert type="note" >}}
In GitLab Ultimate, users with the Guest role do not count towards the license seat usage. You can add Guest users to your GitLab instance without impacting your billable seats.
While the Guest role generally provides limited access, creating a [custom role](../user/custom_roles/_index.md) with the [`View repository code`](../user/custom_roles/abilities.md#source-code-management) permission allows you to provide access to code in your repositories without consuming a license seat. Adding any other permissions causes the role to occupy a billable seat.
While Guest users generally have limited access, you can configure a [custom role](../user/custom_roles/_index.md) that includes the [`View repository code` permission](../user/custom_roles/abilities.md#source-code-management) to allow Guests to read code in your repositories. Adding any other permissions causes the role to occupy a billable seat.
{{< /alert >}}
## Assign Guest role to users
@ -38,38 +49,19 @@ You can assign the Guest role to a current member of a group or project, or assi
To assign the Guest role to a current group or project member:
1. On the left sidebar, select **Search or go to** and find your project or group.
1. On the left sidebar, select **Search or go to** and find your group or project.
1. Select **Manage** > **Members**.
1. In the **Role** column of the group or project member you want to assign the Guest role to, select their current role (for example, **Developer**).
1. In the **Role details** drawer, change the Role to **Guest**.
1. Select **Update role**.
If the user you want to assign the Guest role to is not yet a
member of the project or group:
member of the group or project:
1. On the left sidebar, select **Search or go to** and find your project or group.
1. On the left sidebar, select **Search or go to** and find your group or project.
1. Select **Manage** > **Members**.
1. Select **Invite members**.
1. In **Username, name or email address**, select the relevant user.
1. In **Select a role**, select **Guest**.
1. Optional. In **Access expiration date**, enter a date.
1. Select **Invite**.
## Guest user permissions and restrictions
Users with the Guest role can:
- View project plans, blockers, and progress indicators.
- View high-level project information such as:
- Analytics
- Incident reports
- Issues and epics
- Licenses
- Create and link new project work items.
- Access public groups and public projects.
Users with the Guest role cannot:
- Modify existing data that they have not created.
- View code in GitLab projects by default.
- Create projects, groups, and snippets in their personal namespaces.

6
doc/api/packages/nuget.md
View File

@ -86,6 +86,12 @@ curl --user <username>:<personal_access_token> "https://gitlab.example.com/api/v
This writes the downloaded file to `MyNuGetPkg.1.3.0.17.nupkg` in the current directory.
{{< alert type="note" >}}
This API returns a `404` status when you use [group endpoints](#group-level). Use the NuGet package manager CLI to [install packages](../../user/packages/nuget_repository#install-a-package) with group endpoints to avoid this error.
{{< /alert >}}
## Upload a package file
{{< history >}}

48
doc/install/package/_index.md
View File

@ -36,6 +36,18 @@ systems. Some operating systems, such as Ubuntu, have a clear distinction
between LTS and non-LTS versions. However, there are other operating systems,
openSUSE for example, that don't follow the LTS concept.
### Support policy
We will usually provide support for a version of an operating system until it is no longer supported by its vendor, where support is defined as standard or maintenance support and
not as expanded, extended, or premium support. However, we might end support earlier than the operating system's vendor in these circumstances:
- Business considerations: Including but not limited to low customer adoption, disproportionate maintenance costs, or strategic product direction changes.
- Technical constraints: When third-party dependencies, security requirements, or underlying technology changes make continued support impractical or impossible.
- Vendor actions: When operating system vendors make changes that fundamentally impact our software's functionality or when required components become unavailable.
We will usually issue a deprecation notice at least 6 months before support for any operating system version is discontinued, on a best-effort basis. In cases
where technical constraints, vendor actions, or other external factors require that we provide shorter notice periods, we will communicate any support changes as soon as reasonably possible.
{{< alert type="note" >}}
`amd64` and `x86_64` refer to the same 64-bit architecture. The names `arm64` and `aarch64` are also interchangeable
@ -43,24 +55,24 @@ and refer to the same architecture.
{{< /alert >}}
| Operating system | First supported GitLab version | Architecture | Operating system EOL | Upstream release notes |
|:-----------------|:-------------------------------|:--------------------|:---------------------|:--------|
| [AlmaLinux 8](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 14.5.0 | `x86_64`, `aarch64` <sup>1</sup> | 2029 | [AlmaLinux details](https://almalinux.org/) |
| [AlmaLinux 9](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 16.0.0 | `x86_64`, `aarch64` <sup>1</sup> | 2032 | [AlmaLinux details](https://almalinux.org/) |
| [Amazon Linux 2](https://about.gitlab.com/install/#amazonlinux-2) | GitLab CE / GitLab EE 14.9.0 | `amd64`, `arm64` <sup>1</sup> | June 2026 | [Amazon Linux details](https://aws.amazon.com/amazon-linux-2/faqs/) |
| [Amazon Linux 2023](https://about.gitlab.com/install/#amazonlinux-2023) | GitLab CE / GitLab EE 16.3.0 | `amd64`, `arm64` <sup>1</sup> | 2028 | [Amazon Linux details](https://docs.aws.amazon.com/linux/al2023/ug/release-cadence.html) |
| [Debian 11](https://about.gitlab.com/install/#debian) | GitLab CE / GitLab EE 14.6.0 | `amd64`, `arm64` <sup>1</sup> | 2026 | [Debian Linux details](https://wiki.debian.org/LTS) |
| [Debian 12](https://about.gitlab.com/install/#debian) | GitLab CE / GitLab EE 16.1.0 | `amd64`, `arm64` <sup>1</sup> | TBD | [Debian Linux details](https://wiki.debian.org/LTS) |
| [openSUSE Leap 15.6](https://about.gitlab.com/install/#opensuse-leap) | GitLab CE / GitLab EE 17.6.0 | `x86_64`, `aarch64` <sup>1</sup> | Dec 2025 | [openSUSE details](https://en.opensuse.org/Lifetime) |
| [SUSE Linux Enterprise Server 12](https://about.gitlab.com/install/#opensuse-leap) | GitLab EE 9.0.0 | `x86_64` | Oct 2027 | [SUSE Linux Enterprise Server details](https://www.suse.com/lifecycle/) |
| [SUSE Linux Enterprise Server 15](https://about.gitlab.com/install/#opensuse-leap) | GitLab EE 14.8.0 | `x86_64` | Dec 2024 | [SUSE Linux Enterprise Server details](https://www.suse.com/lifecycle/) |
| [Oracle Linux 8](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 12.8.1 | `x86_64` | July 2029 | [Oracle Linux details](https://www.oracle.com/a/ocom/docs/elsp-lifetime-069338.pdf) |
| [Oracle Linux 9](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 16.2.0 | `x86_64` | June 2032 | [Oracle Linux details](https://www.oracle.com/a/ocom/docs/elsp-lifetime-069338.pdf) |
| [Red Hat Enterprise Linux 8](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 12.8.1 | `x86_64`, `arm64` <sup>1</sup> | May 2029 | [Red Hat Enterprise Linux details](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates) |
| [Red Hat Enterprise Linux 9](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 16.0.0 | `x86_64`, `arm64` <sup>1</sup> | May 2032 | [Red Hat Enterprise Linux details](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates) |
| [Ubuntu 20.04](https://about.gitlab.com/install/#ubuntu) | GitLab CE / GitLab EE 13.2.0 | `amd64`, `arm64` <sup>1</sup> | April 2025 | [Ubuntu details](https://wiki.ubuntu.com/Releases) |
| [Ubuntu 22.04](https://about.gitlab.com/install/#ubuntu) | GitLab CE / GitLab EE 15.5.0 | `amd64`, `arm64` <sup>1</sup> | April 2027 | [Ubuntu details](https://wiki.ubuntu.com/Releases) |
| [Ubuntu 24.04](https://about.gitlab.com/install/#ubuntu) | GitLab CE / GitLab EE 17.1.0 | `amd64`, `arm64` <sup>1</sup> | April 2029 | [Ubuntu details](https://wiki.ubuntu.com/Releases) |
| Operating system | First supported GitLab version | Architecture | Operating system EOL | Proposed last supported GitLab version | Upstream release notes |
|------------------------------------------------------------------------------------|--------------------------------|-----------------------|----------------------|-------------------------------|---------------------------------------------------------------------------------------------------------------|
| [AlmaLinux 8](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 14.5.0 | `x86_64`, `aarch64` <sup>1</sup> | Mar 2029 | GitLab CE / GitLab EE 21.10.0 | [AlmaLinux details](https://almalinux.org/) |
| [AlmaLinux 9](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 16.0.0 | `x86_64`, `aarch64` <sup>1</sup> | May 2032 | GitLab CE / GitLab EE 25.0.0 | [AlmaLinux details](https://almalinux.org/) |
| [Amazon Linux 2](https://about.gitlab.com/install/#amazonlinux-2) | GitLab CE / GitLab EE 14.9.0 | `amd64`, `arm64` <sup>1</sup> | June 2026 | GitLab CE / GitLab EE 19.1.0 | [Amazon Linux details](https://aws.amazon.com/amazon-linux-2/faqs/) |
| [Amazon Linux 2023](https://about.gitlab.com/install/#amazonlinux-2023) | GitLab CE / GitLab EE 16.3.0 | `amd64`, `arm64` <sup>1</sup> | June 2029 | GitLab CE / GitLab EE 22.1.0 | [Amazon Linux details](https://docs.aws.amazon.com/linux/al2023/ug/release-cadence.html) |
| [Debian 11](https://about.gitlab.com/install/#debian) | GitLab CE / GitLab EE 14.6.0 | `amd64`, `arm64` <sup>1</sup> | Aug 2026 | GitLab CE / GitLab EE 19.3.0 | [Debian Linux details](https://wiki.debian.org/LTS) |
| [Debian 12](https://about.gitlab.com/install/#debian) | GitLab CE / GitLab EE 16.1.0 | `amd64`, `arm64` <sup>1</sup> | June 2028 | GitLab CE / GitLab EE 19.3.0 | [Debian Linux details](https://wiki.debian.org/LTS) |
| [openSUSE Leap 15.6](https://about.gitlab.com/install/#opensuse-leap) | GitLab CE / GitLab EE 17.6.0 | `x86_64`, `aarch64` <sup>1</sup> | Dec 2025 | TBD | [openSUSE details](https://en.opensuse.org/Lifetime) |
| [SUSE Linux Enterprise Server 12](https://about.gitlab.com/install/#opensuse-leap) | GitLab EE 9.0.0 | `x86_64` | Oct 2027 | TBD | [SUSE Linux Enterprise Server details](https://www.suse.com/lifecycle/) |
| [SUSE Linux Enterprise Server 15](https://about.gitlab.com/install/#opensuse-leap) | GitLab EE 14.8.0 | `x86_64` | Dec 2024 | TBD | [SUSE Linux Enterprise Server details](https://www.suse.com/lifecycle/) |
| [Oracle Linux 8](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 12.8.1 | `x86_64` | July 2029 | GitLab CE / GitLab EE 22.2.0 | [Oracle Linux details](https://www.oracle.com/a/ocom/docs/elsp-lifetime-069338.pdf) |
| [Oracle Linux 9](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 16.2.0 | `x86_64` | June 2032 | GitLab CE / GitLab EE 25.1.0 | [Oracle Linux details](https://www.oracle.com/a/ocom/docs/elsp-lifetime-069338.pdf) |
| [Red Hat Enterprise Linux 8](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 12.8.1 | `x86_64`, `arm64` <sup>1</sup> | May 2029 | GitLab CE / GitLab EE 22.0.0 | [Red Hat Enterprise Linux details](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates) |
| [Red Hat Enterprise Linux 9](https://about.gitlab.com/install/#almalinux) | GitLab CE / GitLab EE 16.0.0 | `x86_64`, `arm64` <sup>1</sup> | May 2032 | GitLab CE / GitLab EE 25.0.0 | [Red Hat Enterprise Linux details](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates) |
| [Ubuntu 20.04](https://about.gitlab.com/install/#ubuntu) | GitLab CE / GitLab EE 13.2.0 | `amd64`, `arm64` <sup>1</sup> | April 2025 | GitLab CE / GitLab EE 18.3.0 | [Ubuntu details](https://wiki.ubuntu.com/Releases) |
| [Ubuntu 22.04](https://about.gitlab.com/install/#ubuntu) | GitLab CE / GitLab EE 15.5.0 | `amd64`, `arm64` <sup>1</sup> | April 2027 | GitLab CE / GitLab EE 19.11.0 | [Ubuntu details](https://wiki.ubuntu.com/Releases) |
| [Ubuntu 24.04](https://about.gitlab.com/install/#ubuntu) | GitLab CE / GitLab EE 17.1.0 | `amd64`, `arm64` <sup>1</sup> | April 2029 | GitLab CE / GitLab EE 21.11.0 | [Ubuntu details](https://wiki.ubuntu.com/Releases) |
**Footnotes**:

23
doc/user/project/merge_requests/approvals/rules.md
View File

@ -121,11 +121,13 @@ For an overview, see [Multiple Approvers](https://www.youtube.com/watch?v=8JQJ58
## Eligible approvers
To be eligible as an approver for a project, a user must be a member of at least one of the following:
To be eligible as an approver for your project, a user must be a direct member of at least one of the following:
- The project.
- The project's immediate parent [group](#group-approvers).
- A group that has been [shared](../../members/sharing_projects_groups.md) with the project.
- Your project.
- Your project's group.
- Any of your project's group's parent groups.
- Another group that has been [shared with your project](../../members/sharing_projects_groups.md#sharing-projects).
- Another group that has been [shared with your project's group or any of the group's parents](../../members/sharing_projects_groups.md#sharing-groups).
- A [group added as approvers](#group-approvers).
Users with the Developer role can approve merge requests if one of the following is true:
@ -165,9 +167,12 @@ You can add a group of users as approvers. All direct members of this group
can approve the rule. Inherited members cannot approve the rule.
Typically the group is a subgroup in your top-level namespace, unless you are
collaborating with an external group. If you are collaborating with another group,
you must [share access to the project](../../members/sharing_projects_groups.md)
before assigning the group as a group approver.
collaborating with an external group. If you are collaborating with another group
and want to use members of that group as approvers, you can either:
- [Share access to the project](../../members/sharing_projects_groups.md#sharing-projects).
- [Share access to your project's group](../../members/sharing_projects_groups.md#sharing-groups),
which gives the external group approval access to all projects in your project's group.
A user's membership in an approver group determines their individual approval permissions
in the following ways:
@ -179,8 +184,8 @@ in the following ways:
To change this behavior, disable the
[**Prevent author approval**](settings.md#prevent-approval-by-author)
project setting.
- Committers to merge requests can approve a merge request. To change this behavior, enable the
[**Prevent committers approval**](settings.md#prevent-approvals-by-users-who-add-commits)
- By default, committers to merge requests can approve a merge request. To change this behavior, enable
the [**Prevent committers approval**](settings.md#prevent-approvals-by-users-who-add-commits)
project setting.
### Code owners as eligible approvers

2
doc/user/project/repository/code_suggestions/_index.md
View File

@ -26,7 +26,7 @@ title: Code Suggestions
- [Changed](https://gitlab.com/gitlab-org/fulfillment/meta/-/issues/2031) to require the GitLab Duo Pro add-on on February 15, 2024. Previously, this feature was included with Premium and Ultimate subscriptions.
- [Changed](https://gitlab.com/gitlab-org/fulfillment/meta/-/issues/2031) to require the GitLab Duo Pro or GitLab Duo Enterprise add-on for all supported GitLab versions starting October 17, 2024.
- [Introduced support for Fireworks AI-hosted Qwen2.5 code completion model](https://gitlab.com/groups/gitlab-org/-/epics/15850) in GitLab 17.6, with a flag named `fireworks_qwen_code_completion`.
- Removed support for Qwen2.5 code completion model
- [Removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/187397) support for Qwen2.5 code completion model in GitLab 17.11
- Enabled Fireworks hosted `Codestral` by default via the feature flag `use_fireworks_codestral_code_completion` in GitLab 17.11
- Changed to include GitLab Duo Core in GitLab 18.0.
- Enabled Fireworks hosted `Codestral` as the default model in GitLab 18.1