Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
c449ce987e
commit
2937dbf95a
|
|
@ -5,7 +5,7 @@ workflow:
|
|||
name: $PIPELINE_NAME
|
||||
|
||||
include:
|
||||
- component: "gitlab.com/gitlab-org/quality/pipeline-common/allure-report@8.3.0"
|
||||
- component: "gitlab.com/gitlab-org/quality/pipeline-common/allure-report@8.5.1"
|
||||
inputs:
|
||||
job_name: "e2e-test-report"
|
||||
job_stage: "report"
|
||||
|
|
|
|||
|
|
@ -215,7 +215,6 @@ Layout/LineEndStringConcatenationIndentation:
|
|||
- 'rubocop/cop/redis_queue_usage.rb'
|
||||
- 'rubocop/cop/rspec/factory_bot/inline_association.rb'
|
||||
- 'rubocop/cop/rspec/factory_bot/strategy_in_callback.rb'
|
||||
- 'rubocop/cop/rspec/have_gitlab_http_status.rb'
|
||||
- 'rubocop/cop/sidekiq_api_usage.rb'
|
||||
- 'rubocop/cop/user_admin.rb'
|
||||
- 'scripts/lib/glfm/parse_examples.rb'
|
||||
|
|
|
|||
|
|
@ -4919,7 +4919,6 @@ RSpec/FeatureCategory:
|
|||
- 'spec/rubocop/cop/rspec/factory_bot/avoid_create_spec.rb'
|
||||
- 'spec/rubocop/cop/rspec/factory_bot/inline_association_spec.rb'
|
||||
- 'spec/rubocop/cop/rspec/factory_bot/strategy_in_callback_spec.rb'
|
||||
- 'spec/rubocop/cop/rspec/have_gitlab_http_status_spec.rb'
|
||||
- 'spec/rubocop/cop/rspec/modify_sidekiq_middleware_spec.rb'
|
||||
- 'spec/rubocop/cop/rspec/top_level_describe_path_spec.rb'
|
||||
- 'spec/rubocop/cop/rspec/web_mock_enable_spec.rb'
|
||||
|
|
|
|||
|
|
@ -54,7 +54,6 @@ Style/Lambda:
|
|||
- 'lib/gitlab/utils/usage_data.rb'
|
||||
- 'qa/qa/runtime/allure_report.rb'
|
||||
- 'rubocop/cop/inject_enterprise_edition_module.rb'
|
||||
- 'rubocop/cop/rspec/have_gitlab_http_status.rb'
|
||||
- 'spec/controllers/concerns/routable_actions_spec.rb'
|
||||
- 'spec/features/groups/dependency_proxy_for_containers_spec.rb'
|
||||
- 'spec/graphql/types/base_object_spec.rb'
|
||||
|
|
|
|||
|
|
@ -144,7 +144,7 @@ GitLab Dedicated limits the number of reverse PrivateLink connections to 10.
|
|||
|
||||
### IP allowlist
|
||||
|
||||
GitLab Dedicated allows you to control which IP addresses can access your instance through an IP allowlist. Once the IP allowlist has been enabled, when an IP not on the allowlist tries to access your instance an `HTTP 403 Forbidden` response is returned.
|
||||
GitLab Dedicated allows you to control which IP addresses can access your instance through an IP allowlist. Once the IP allowlist has been enabled, when an IP not on the allowlist tries to access your instance an `HTTP 403 Forbidden` response is returned. The IP allowlist is applied to incoming Web requests only and does not apply to incoming SSH requests.
|
||||
|
||||
IP addresses that have been added to your IP allowlist can be viewed on the Configuration page in Switchboard. You can add or remove IP addresses from your allowlist with Switchboard or a support request.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,48 @@
|
|||
---
|
||||
owning-stage: "~devops::create"
|
||||
description: 'AI Gateway ADR 001: Allow direct connections'
|
||||
---
|
||||
|
||||
# AI Gateway ADR 001: Allow direct connections
|
||||
|
||||
NOTE:
|
||||
This decision is scoped to code completion requests. Code completion requests are a type of [code suggestion request](../../../../user/project/repository/code_suggestions/index.md).
|
||||
|
||||
## Summary
|
||||
|
||||
Code completion requests will be sent directly from client to AI Gateway, while code generation requests will still be sent indirectly through GitLab Rails.
|
||||
|
||||
## Context
|
||||
|
||||
The original iteration of the blueprint suggested to route all code suggestion requests to AI Gateway indirectly through GitLab Rails.
|
||||
There were multiple reasons for this:
|
||||
|
||||
- the decision if a code suggestion request is a completion or generation request was done on GitLab Rails side
|
||||
- Simpler authentication of requests could be used. For example, we could use instance JWT tokens to authenticate requests from self-managed instances.
|
||||
|
||||
In [epic 12224](https://gitlab.com/groups/gitlab-org/-/epics/12224), we discussed various
|
||||
options to decrease request latency which would decrease also overall response
|
||||
time.
|
||||
|
||||
## Decision
|
||||
|
||||
In the epic we decided to use different request flows for code completion and code generation requests. The reason is that both request types are slightly different:
|
||||
|
||||
- Code completion requests are much more sensitive to latency and from the request [timing breakdown](https://gitlab.com/groups/gitlab-org/-/epics/12224#latency-breakdown-by-components), more than 50% of time is spent connecting to the AI provider.
|
||||
- Code generation requests are not so sensitive to latency. Most of the request time is spent on AI provider side and latency optimization would have marginal effect in the overall response time. Also we enrich these requests with additional data in GitLab Rails so it's still important to route these requests through GitLab Rails.
|
||||
|
||||
For code completion requests we decided that these requests can be sent by clients directly to AI Gateway. This will decrease latency by 150ms. We will benefit from this also when AI Gateway supports [multi-region deployments](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1206) because then code completion requests can be handled inside the same region. GitLab Rails does not support multi-region deployment, so with having completion requests routed through GitLab Rails we cannot eliminate long-distance connection hops which increases latency as well.
|
||||
|
||||
Usage of direct connection will be optional optimization. If a client does not recognize that a request is of type "completion", then it can still send the request through GitLab Rails as is now.
|
||||
|
||||
We considered also using the websocket protocol, but for now we will keep using HTTP. The plan is to use short-term JWTs to authenticate direct connections. This should be a fast operation (we use this already for requests sent indirectly) and it duplicates the major advantage of websocket. With websocket, we can authenticate users only once when opening the connection. So although with websocket, the connection might be faster by a few milliseconds, it does not outweighs downsides. This means mainly much more work both on AI Gateway and client side to switch to a different protocol. Also websocket is a stateful protocol which would complicate AI Gateway multi-region support.
|
||||
|
||||
Latency will improve even further for non-US GitLab users when multi-region deployment of AI-gateway is supported. We then avoid long-distance connection hop client<->GitLab Rails.
|
||||
|
||||
## Consequences
|
||||
|
||||
- No pre-processing for code completions requests by GitLab Rails. We currently do not do any special pre-processing of code completion requests on GitLab Rails side. If we want to do it in future, a possible approach would be to pre-fetch GitLab-specific data and do this enrichment on the client side as outlined in [this comment](https://gitlab.com/groups/gitlab-org/-/epics/12224#note_1744581116).
|
||||
- Cloud Connector needs to be able to authenticate these direct connections. We will use short-term JWTs issued for end users. As decided in [issue 168](https://gitlab.com/gitlab-org/cloud-connector-team/team-tasks/-/issues/168) that AI Gateway will issue these short-term tokens.
|
||||
- To fully leverage this optimization, we will need to support request type recognition (completion vs generation) on the client side. This is already supported for some clients and languages, but ideally we should support it for most of frequently used editors and programming languages.
|
||||
- Client initialization process needs to be updated. Clients will receive short-term token with other direct connection details from GitLab Rails instance. For more information, see [issue 66](https://gitlab.com/gitlab-org/editor-extensions/meta/-/issues/66)
|
||||
- AI Gateway should support monitoring and rate-limiting which is now handled by GitLab Rails.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 89 KiB After Width: | Height: | Size: 94 KiB |
|
|
@ -24,22 +24,26 @@ will use the same gateway. However, in the future we could also deploy
|
|||
regional gateways, or even customer-specific gateways if the need
|
||||
arises.
|
||||
|
||||
The AI-Gateway is an API-Gateway that takes traffic from clients, in
|
||||
this case GitLab installations, and directing it to different
|
||||
services, in this case AI-providers and their models. This North/South
|
||||
traffic pattern allows us to control what requests go where and to
|
||||
translate the content of the redirected request where needed.
|
||||
The AI-Gateway is an API-Gateway that handles traffic steered to it from a
|
||||
globally reachable `cloud.gitlab.com/ai/*` route. IDEs currently use `cloud.gitlab.com/ai/*`
|
||||
indirectly through a GitLab Rails instance. In
|
||||
future we plan to allow network endpoints such as IDEs to connect directly to
|
||||
`cloud.gitlab.com` (for more information, see [directly connected clients](#directly-connected-clients)).
|
||||
The AI-Gateway then directs this traffic to other services, in this case
|
||||
AI-providers and their models. This north/south traffic pattern allows us to
|
||||
control what requests go where and to translate the content of the redirected
|
||||
request where needed.
|
||||
|
||||
|
||||
|
||||
**Currently, multi-region deployment is not supported; it's a feature under consideration. The existing diagram illustrates a potential architecture for deploying across multiple regions.**
|
||||
|
||||
[Diagram source](https://docs.google.com/drawings/d/1PYl5Q5oWHnQAuxM-Jcw0C3eYoGw8a9w8atFpoLhhEas/edit)
|
||||
[Diagram source](https://docs.google.com/drawings/d/1xhGElN4rGvCY-SOvSkRpSdZ_MZ3IgVQiiTlKQpkPyLE/edit)
|
||||
|
||||
By using a hosted service under the control of GitLab we can ensure
|
||||
that we provide all GitLab instances with AI features in a scalable
|
||||
way. It is easier to scale this small stateless service, than scaling
|
||||
GitLab-rails with it's dependencies (database, Redis).
|
||||
GitLab Rails with its dependencies (database, Redis).
|
||||
|
||||
It allows users of self-managed installations to have access to
|
||||
features using AI without them having to host their own models or
|
||||
|
|
@ -56,16 +60,30 @@ Rubyists to pick up through in the younger codebase that is the
|
|||
AI-gateway. It also makes it easy for data- and ML-engineers that
|
||||
already have Python experience to contribute.
|
||||
|
||||
## Directly connected clients
|
||||
|
||||
Direct connections are not supported yet and this work is tracked in
|
||||
[this epic](https://gitlab.com/groups/gitlab-org/-/epics/12224#proposed-solution).
|
||||
|
||||
Decision: [ADR-001: Allow direct connections](decisions/001_direct_connections.md)
|
||||
|
||||
Code completion requests will be sent directly from a client to AI Gateway to
|
||||
improve latency of these requests. It will be up to the client to decide if a
|
||||
request can be sent directly to AI Gateway or to GitLab Rails for additional
|
||||
enrichment. Usage of direct connections will be optional and backward
|
||||
compatible. If a client will not support detection of completion requests, it
|
||||
can still send these requests through GitLab Rails (as is now) without
|
||||
specifying the type of code suggestion request.
|
||||
|
||||
## API
|
||||
|
||||
### Basic stable API for the AI-gateway
|
||||
|
||||
Because the API of the AI-gateway will be consumed by a wide variety
|
||||
of GitLab instances, it is important that we design a stable, yet
|
||||
flexible API.
|
||||
of clients, it is important that we design a stable, yet flexible API.
|
||||
|
||||
To do this, we can implement an API-endpoint per use-case we
|
||||
build. This means that the interface between GitLab and the AI-gateway
|
||||
build. This means that the interface between client and the AI-gateway
|
||||
is one that we build and own. This ensures future scalability,
|
||||
composability and security.
|
||||
|
||||
|
|
@ -74,8 +92,9 @@ for details. The AI-gateway will support the last 2 major
|
|||
versions. For example when working on GitLab 17.2, we would support
|
||||
both GitLab 17 and GitLab 16.
|
||||
|
||||
We can add common functionality like rate-limiting, circuit-breakers and
|
||||
secret redaction at this level of the stack as well as in GitLab-rails.
|
||||
Because clients can connect directly to AI Gateway, common functionality like
|
||||
rate-limiting, circuit-breakers and secret redaction should be added both at
|
||||
this level of the stack as well as in GitLab Rails.
|
||||
|
||||
#### Protocol
|
||||
|
||||
|
|
@ -83,7 +102,7 @@ The communication between the AI-Gateway service and its clients (including the
|
|||
|
||||
The AI-Gateway API shall expose single-purpose endpoints responsible for providing access to different AI features. [A later section](#single-purpose-endpoints) of this document provides detailed guidelines for building specific endpoints.
|
||||
|
||||
The AI Gateway communication protocol shall only expect a rudimentary envelope that wraps all feature-specific dynamic information. The proposed architecture of the protocol allows the API endpoints to be version agnostic, and the AI-Gateway APIs compatible with multiple versions of GitLab(or other clients that use the gateway through GitLab).
|
||||
The AI Gateway communication protocol shall only expect a rudimentary envelope that wraps all feature-specific dynamic information. The proposed architecture of the protocol allows the API endpoints to be version agnostic, and the AI-Gateway APIs compatible with multiple versions of GitLab(or other clients that use the gateway).
|
||||
|
||||
**This means
|
||||
that all clients regardless of their versions use the same set of AI-Gateway API feature endpoints. The AI-gateway feature endpoints have to support different client versions, instead of creating multiple feature endpoints per different supported client versions**.
|
||||
|
|
@ -139,8 +158,8 @@ Our goal is to minimize code that we can't update on a customer's behalf, which
|
|||
- We want a single point for controlling and measuring cost.
|
||||
- As much as possible, we want to track metrics (usage statistics, failures to respond, usage pattern, question categories, etc.) in the gateway rather than distributed across many points. (Of course some metrics can only be captured on the client side.)
|
||||
|
||||
Having the business logic in GitLab-Rails requires customers to upgrade their GitLab instances, which affects the first point. Some of the on-premises users can't upgrade their instances immediately due to their company policy.
|
||||
For example, if we had a bug in a prompt template in GitLab-Rails and fixed it in 16.6, and customers are using 16.5 and the next upgrade is scheduled in 3 months, they have to use the buggy feature for 3 months.
|
||||
Having the business logic in GitLab Rails requires customers to upgrade their GitLab instances, which affects the first point. Some of the on-premises users cannot upgrade their instances immediately due to their company policy.
|
||||
For example, if we had a bug in a prompt template in GitLab Rails and fixed it in 16.6, and customers are using 16.5 and the next upgrade is scheduled in 3 months, they have to use the buggy feature for 3 months.
|
||||
|
||||
**This does not mean that prompts need to be built inside the
|
||||
AI-gateway.** But if prompts are part of the payload to a single
|
||||
|
|
@ -153,7 +172,7 @@ GitLab installations as the AI landscape changes.
|
|||
|
||||
### The AI-Gateway API protocol
|
||||
|
||||
It is important to build each single-purpose endpoint, in a version-agnostic way so it can be used by different GitLab instances (and indirectly by external clients). To achieve this goal:
|
||||
It is important to build each single-purpose endpoint, in a version-agnostic way so it can be used by different GitLab instances and by external clients. To achieve this goal:
|
||||
|
||||
**The AI-Gateway protocol shall rely on a simple JSON envelope wrapping all feature-specific information.** The AI-Gateway protocol can be seen as a transport layer protocol from [the OSI model](https://en.wikipedia.org/wiki/OSI_model) (eg: TCP, UDP) which defines how to transport information between nodes, without being aware of what information is being transported.
|
||||
|
||||
|
|
@ -345,7 +364,7 @@ We will try to come up with an architecture for all AI-related features.
|
|||
|
||||
#### Exposing AI providers
|
||||
|
||||
A lot of AI functionality has already been built into GitLab-Rails
|
||||
A lot of AI functionality has already been built into GitLab Rails
|
||||
that currently builds prompts and submits this directly to different
|
||||
AI providers. At the time of writing, GitLab has API-clients for the
|
||||
following providers:
|
||||
|
|
@ -416,7 +435,7 @@ clients as for the AI gateway.
|
|||
|
||||
In a first iteration we could consider keeping the current REST
|
||||
payloads that the VSCode extension and the Web-IDE send, but direct it
|
||||
to the appropriate GitLab installation. GitLab-rails can wrap the
|
||||
to the appropriate GitLab installation. GitLab Rails can wrap the
|
||||
payload in an envelope for the AI-gateway without having to interpret
|
||||
it.
|
||||
|
||||
|
|
@ -427,7 +446,7 @@ it on to the AI-Gateway. GitLab can add information to the
|
|||
straight through to the AI-gateway.
|
||||
|
||||
If a request is initiated from another client (for example VSCode),
|
||||
GitLab-rails needs to forward the entire payload in addition to any
|
||||
GitLab Rails needs to forward the entire payload in addition to any
|
||||
other enhancements and prompts. This is required so we can potentially
|
||||
support changes from a newer version of the client, traveling through
|
||||
an outdated GitLab installation to a recent AI-gateway.
|
||||
|
|
@ -457,6 +476,18 @@ in:
|
|||
The specific mechanism by which trust is delegated between end-users, GitLab instances,
|
||||
and the AI-gateway is covered in the [Cloud Connector access control documentation](../../../development/cloud_connector/architecture.md#access-control).
|
||||
|
||||
AI Gateway is accessed only through Cloud connector which handles instance
|
||||
authentication (among others). Cloud connector will need to support also end-user
|
||||
authentication because some requests (e.g. code completion) will be sent
|
||||
directly by clients instead of sending all requests indirectly through
|
||||
GitLab Rails. A possible solution in
|
||||
which short-term user tokens are used is described in [Epic 13252](https://gitlab.com/groups/gitlab-org/-/epics/13252).
|
||||
AI Gateway needs to be able to distinguish between requests proxied by
|
||||
GitLab Rails and direct client requests because some endpoints or parameters
|
||||
may not be available for direct requests (for example clients should not be
|
||||
able to send final prompt, but rather only sub-components from which the final
|
||||
prompt is built by AI Gateway).
|
||||
|
||||
## Embeddings
|
||||
|
||||
Embeddings can be requested for all features in a single endpoint, for
|
||||
|
|
@ -523,3 +554,7 @@ Further testing strategy is being discussed in
|
|||
|
||||
Alternative solutions were discussed in
|
||||
[applied-ml/code-suggestions/ai-assist#161](https://gitlab.com/gitlab-org/modelops/applied-ml/code-suggestions/ai-assist/-/issues/161#what-are-the-alternatives).
|
||||
|
||||
## Decisions
|
||||
|
||||
- [ADR-001: Allow direct connections](decisions/001_direct_connections.md)
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ If you need to configure runners on the machine where you installed GitLab Runne
|
|||
|
||||
You can specify a maximum job timeout for each runner to prevent projects
|
||||
with longer job timeouts from using the runner. The maximum job timeout is
|
||||
used of it is shorter than the job timeout defined in the project.
|
||||
used if it is shorter than the job timeout defined in the project.
|
||||
|
||||
### For an instance runner
|
||||
|
||||
|
|
|
|||
|
|
@ -265,6 +265,11 @@ If duplicate environment variables are present in a `dotenv` report:
|
|||
- In GitLab 14.6 and later, the last one specified is used.
|
||||
- In GitLab 14.5 and earlier, an error occurs.
|
||||
|
||||
You should avoid storing sensitive data like credentials in dotenv reports, as the
|
||||
reports can be downloaded from the pipeline details page. If necessary, you can use
|
||||
[artifacts:access](index.md#artifactsaccess) to restrict the users that can download
|
||||
the report artifacts in a job.
|
||||
|
||||
The exceptions to the [original dotenv rules](https://github.com/motdotla/dotenv#rules) are:
|
||||
|
||||
- The variable key can contain only letters, digits, and underscores (`_`).
|
||||
|
|
|
|||
|
|
@ -1444,10 +1444,10 @@ You cannot use [`artifacts:public`](#artifactspublic) and `artifacts:access` in
|
|||
|
||||
**Possible inputs**:
|
||||
|
||||
- `all` (default): Artifacts in public pipelines are available for download by anyone, including anonymous,
|
||||
guest, and reporter users.
|
||||
- `developer`: Artifacts are only available for download by users with the Developer role or higher.
|
||||
- `none`: Artifacts are not available for download by anyone.
|
||||
- `all` (default): Artifacts in a job in public pipelines are available for download by anyone,
|
||||
including anonymous, guest, and reporter users.
|
||||
- `developer`: Artifacts in the job are only available for download by users with the Developer role or higher.
|
||||
- `none`: Artifacts in the job are not available for download by anyone.
|
||||
|
||||
**Example of `artifacts:access`**:
|
||||
|
||||
|
|
@ -1457,6 +1457,11 @@ job:
|
|||
access: 'developer'
|
||||
```
|
||||
|
||||
**Additional details**:
|
||||
|
||||
- `artifacts:access` affects all [`artifacts:reports`](#artifactsreports) too,
|
||||
so you can also restrict access to [artifacts for reports](artifacts_reports.md).
|
||||
|
||||
#### `artifacts:reports`
|
||||
|
||||
Use [`artifacts:reports`](artifacts_reports.md) to collect artifacts generated by
|
||||
|
|
|
|||
|
|
@ -161,6 +161,20 @@ After migration:
|
|||
If you used a private network on your source instance to hide content from the general public,
|
||||
make sure to have a similar setup on the destination instance, or to import into a private group.
|
||||
|
||||
## Memberships
|
||||
|
||||
> - Importing of shared and inherited shared members was [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/129017) in GitLab 16.3.
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148220) in GitLab 16.11, shared and inherited shared members are no longer imported as direct members if they are already shared or inherited shared members of the imported group or project.
|
||||
|
||||
Group and project members are imported if the [user account prerequisites](#user-accounts) are followed.
|
||||
|
||||
All [direct and indirect](../../../user/project/members/index.md#membership-types) members are imported.
|
||||
|
||||
Indirect members are imported as [direct members](../../project/members/index.md#membership-types) if:
|
||||
|
||||
- They are not already an indirect member.
|
||||
- They are an indirect member, but have a lower [permission](../../../user/permissions.md).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
> - Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5.
|
||||
|
|
@ -349,7 +363,7 @@ Group items that are migrated to the destination GitLab instance include:
|
|||
| Group labels <sup>2</sup> | [GitLab 13.9](https://gitlab.com/gitlab-org/gitlab/-/issues/292429) |
|
||||
| Iterations | [GitLab 13.10](https://gitlab.com/gitlab-org/gitlab/-/issues/292428) |
|
||||
| Iteration cadences | [GitLab 15.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96570) |
|
||||
| Members <sup>3</sup> | [GitLab 13.9](https://gitlab.com/gitlab-org/gitlab/-/issues/299415) |
|
||||
| Members <sup>3</sup> | [GitLab 13.9](https://gitlab.com/gitlab-org/gitlab/-/issues/299415) |
|
||||
| Group milestones | [GitLab 13.10](https://gitlab.com/gitlab-org/gitlab/-/issues/292427) |
|
||||
| Namespace settings | [GitLab 14.10](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85128) |
|
||||
| Release milestones | [GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/339422) |
|
||||
|
|
@ -362,9 +376,7 @@ Group items that are migrated to the destination GitLab instance include:
|
|||
metadata [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63551) in GitLab 14.0.
|
||||
1. Group Labels cannot retain any associated Label Priorities during import. These labels will need to be re-prioritized manually
|
||||
once the relevant Project is migrated to the destination instance.
|
||||
1. Group members are associated with the imported group if the user:
|
||||
- Already exists in the destination GitLab instance.
|
||||
- Has a public email in the source GitLab instance that matches a confirmed email in the destination GitLab instance.
|
||||
1. See [Memberships](#memberships).
|
||||
|
||||
### Excluded items
|
||||
|
||||
|
|
@ -425,7 +437,7 @@ Project items that are migrated to the destination GitLab instance include:
|
|||
| Issue boards | [GitLab 14.4](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71661) |
|
||||
| Labels | [GitLab 14.4](https://gitlab.com/gitlab-org/gitlab/-/issues/339419) |
|
||||
| LFS Objects | [GitLab 14.8](https://gitlab.com/gitlab-org/gitlab/-/issues/339405) |
|
||||
| Members | [GitLab 14.8](https://gitlab.com/gitlab-org/gitlab/-/issues/341886) |
|
||||
| Members <sup>2</sup> | [GitLab 14.8](https://gitlab.com/gitlab-org/gitlab/-/issues/341886) |
|
||||
| Merge requests | [GitLab 14.5](https://gitlab.com/gitlab-org/gitlab/-/issues/339403) |
|
||||
| Push rules | [GitLab 14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/339403) |
|
||||
| Milestones | [GitLab 14.5](https://gitlab.com/gitlab-org/gitlab/-/issues/339417) |
|
||||
|
|
@ -445,6 +457,7 @@ Project items that are migrated to the destination GitLab instance include:
|
|||
|
||||
1. Imported branches respect the [default branch protection settings](../../project/protected_branches.md)
|
||||
of the destination group, which could cause an unprotected branch to be imported as protected.
|
||||
1. See [Memberships](#memberships).
|
||||
|
||||
### Issue-related items
|
||||
|
||||
|
|
|
|||
|
|
@ -6,6 +6,9 @@ module BulkImports
|
|||
class MembersPipeline
|
||||
include Pipeline
|
||||
|
||||
GROUP_MEMBER_RELATIONS = %i[direct inherited shared_from_groups].freeze
|
||||
PROJECT_MEMBER_RELATIONS = %i[direct inherited invited_groups shared_into_ancestors].freeze
|
||||
|
||||
transformer Common::Transformers::ProhibitedAttributesTransformer
|
||||
transformer Common::Transformers::MemberAttributesTransformer
|
||||
|
||||
|
|
@ -40,15 +43,27 @@ module BulkImports
|
|||
end
|
||||
|
||||
def existing_user_membership(user_id)
|
||||
members_finder.execute.find_by_user_id(user_id)
|
||||
execute_finder.find_by_user_id(user_id)
|
||||
end
|
||||
|
||||
def members_finder
|
||||
@members_finder ||= if context.entity.group?
|
||||
::GroupMembersFinder.new(portable, current_user)
|
||||
else
|
||||
::MembersFinder.new(portable, current_user)
|
||||
end
|
||||
def finder
|
||||
@finder ||= if context.entity.group?
|
||||
::GroupMembersFinder.new(portable, current_user)
|
||||
else
|
||||
::MembersFinder.new(portable, current_user)
|
||||
end
|
||||
end
|
||||
|
||||
def execute_finder
|
||||
finder.execute(include_relations: finder_relations)
|
||||
end
|
||||
|
||||
def finder_relations
|
||||
if context.entity.group?
|
||||
GROUP_MEMBER_RELATIONS
|
||||
else
|
||||
PROJECT_MEMBER_RELATIONS
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -15,9 +15,10 @@ module Gitlab
|
|||
private
|
||||
|
||||
def graphql_request(query)
|
||||
is_default_host = (URI.parse(api_endpoint).host == URI.parse(::Octokit::Default::API_ENDPOINT).host)
|
||||
with_retry do
|
||||
octokit.post(
|
||||
'/graphql',
|
||||
"#{'/api' unless is_default_host}/graphql",
|
||||
{ query: query }.to_json
|
||||
).to_h
|
||||
end
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@
|
|||
"deckar01-task_list": "^2.3.1",
|
||||
"dexie": "^3.2.3",
|
||||
"diff": "^3.4.0",
|
||||
"dompurify": "^3.0.11",
|
||||
"dompurify": "^3.1.0",
|
||||
"dropzone": "^4.2.0",
|
||||
"editorconfig": "^0.15.3",
|
||||
"emoji-regex": "^10.0.0",
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ module RuboCop
|
|||
'`response.status`.'
|
||||
|
||||
MSG_UNKNOWN_STATUS = 'HTTP status `%{code}` is unknown. ' \
|
||||
'Please provide a valid one or disable this cop.'
|
||||
'Please provide a valid one or disable this cop.'
|
||||
|
||||
MSG_DOCS_LINK = 'https://docs.gitlab.com/ee/development/testing_guide/best_practices.html#have_gitlab_http_status'
|
||||
|
||||
|
|
@ -91,9 +91,9 @@ module RuboCop
|
|||
end
|
||||
|
||||
def corrector(node)
|
||||
lambda do |corrector|
|
||||
->(corrector) do
|
||||
replacement = replace_matcher(node) || replace_response_status(node)
|
||||
corrector.replace(node.source_range, replacement)
|
||||
corrector.replace(node.source_range, replacement) if node.source_range.source != replacement
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ RSpec.describe BulkImports::Common::Pipelines::MembersPipeline, feature_category
|
|||
end
|
||||
end
|
||||
|
||||
context 'when membership with higher access level exists in parent group' do
|
||||
context 'when membership has higher access level than membership in parent group' do
|
||||
it 'creates new direct membership' do
|
||||
data = member_data.merge(access_level: Gitlab::Access::MAINTAINER)
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ RSpec.describe BulkImports::Common::Pipelines::MembersPipeline, feature_category
|
|||
end
|
||||
end
|
||||
|
||||
context 'when membership with lower access level exists in parent group' do
|
||||
context 'when membership has lower access level than membership in parent group' do
|
||||
it 'does not create new membership' do
|
||||
data = member_data.merge(access_level: Gitlab::Access::GUEST)
|
||||
|
||||
|
|
@ -152,20 +152,96 @@ RSpec.describe BulkImports::Common::Pipelines::MembersPipeline, feature_category
|
|||
end
|
||||
|
||||
context 'when importing to group' do
|
||||
let(:portable) { create(:group) }
|
||||
let_it_be(:portable) { create(:group) }
|
||||
|
||||
let(:portable_with_parent) { create(:group, parent: parent) }
|
||||
let(:entity) { create(:bulk_import_entity, :group_entity, group: portable, bulk_import: bulk_import) }
|
||||
let(:entity_with_parent) { create(:bulk_import_entity, :group_entity, group: portable_with_parent, bulk_import: bulk_import) }
|
||||
|
||||
include_examples 'members import'
|
||||
|
||||
context 'when user is a member of group through group sharing' do
|
||||
before_all do
|
||||
group = create(:group)
|
||||
group.add_developer(member_user1)
|
||||
create(:group_group_link, shared_group: portable, shared_with_group: group)
|
||||
end
|
||||
|
||||
it 'does not create new membership' do
|
||||
expect { pipeline.load(context, member_data) }.not_to change(Member, :count)
|
||||
end
|
||||
|
||||
context 'when membership is a higher access level' do
|
||||
it 'creates new direct membership' do
|
||||
data = member_data.merge(access_level: Gitlab::Access::MAINTAINER)
|
||||
|
||||
expect { pipeline.load(context, data) }.to change(portable.members, :count).by(1)
|
||||
|
||||
member = portable.members.find_by_user_id(member_user1.id)
|
||||
|
||||
expect(member.access_level).to eq(Gitlab::Access::MAINTAINER)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when importing to project' do
|
||||
let(:portable) { create(:project) }
|
||||
let_it_be(:portable) { create(:project) }
|
||||
|
||||
let(:portable_with_parent) { create(:project, namespace: parent) }
|
||||
let(:entity) { create(:bulk_import_entity, :project_entity, project: portable, bulk_import: bulk_import) }
|
||||
let(:entity_with_parent) { create(:bulk_import_entity, :project_entity, project: portable_with_parent, bulk_import: bulk_import) }
|
||||
|
||||
include_examples 'members import'
|
||||
|
||||
context 'when project is shared with a group, and user is a direct member of the group' do
|
||||
before_all do
|
||||
group = create(:group)
|
||||
group.add_developer(member_user1)
|
||||
create(:project_group_link, project: portable, group: group)
|
||||
end
|
||||
|
||||
it 'does not create new membership' do
|
||||
expect { pipeline.load(context, member_data) }.not_to change(Member, :count)
|
||||
end
|
||||
|
||||
context 'when membership is a higher access level' do
|
||||
it 'creates new direct membership' do
|
||||
data = member_data.merge(access_level: Gitlab::Access::MAINTAINER)
|
||||
|
||||
expect { pipeline.load(context, data) }.to change(portable.members, :count).by(1)
|
||||
|
||||
member = portable.members.find_by_user_id(member_user1.id)
|
||||
|
||||
expect(member.access_level).to eq(Gitlab::Access::MAINTAINER)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when parent group is shared with other group, and user is a member of other group' do
|
||||
let(:tracker) { create(:bulk_import_tracker, entity: entity_with_parent) }
|
||||
|
||||
before do
|
||||
group = create(:group)
|
||||
group.add_developer(member_user1)
|
||||
create(:group_group_link, shared_group: parent, shared_with_group: group)
|
||||
end
|
||||
|
||||
it 'does not create new membership' do
|
||||
expect { pipeline.load(context, member_data) }.not_to change(Member, :count)
|
||||
end
|
||||
|
||||
context 'when membership is a higher access level' do
|
||||
it 'creates new direct membership' do
|
||||
data = member_data.merge(access_level: Gitlab::Access::MAINTAINER)
|
||||
|
||||
expect { pipeline.load(context, data) }.to change(portable_with_parent.members, :count).by(1)
|
||||
|
||||
member = portable_with_parent.members.find_by_user_id(member_user1.id)
|
||||
|
||||
expect(member.access_level).to eq(Gitlab::Access::MAINTAINER)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -677,6 +677,20 @@ RSpec.describe Gitlab::GithubImport::Client, feature_category: :importers do
|
|||
client.search_repos_by_name_graphql('test')
|
||||
end
|
||||
|
||||
context 'when api_endpoint is not api.github.com' do
|
||||
it 'uses the graphql api path for a self-hosted instance' do
|
||||
expect(client)
|
||||
.to receive(:api_endpoint)
|
||||
.and_return('https://github.kittens.com/')
|
||||
|
||||
expect(client.octokit).to receive(:post).with(
|
||||
'/api/graphql', { query: expected_graphql }.to_json
|
||||
)
|
||||
|
||||
client.search_repos_by_name_graphql('test')
|
||||
end
|
||||
end
|
||||
|
||||
context 'when relation type option present' do
|
||||
context 'when relation type is owned' do
|
||||
let(:expected_query) { 'test in:name is:public,private fork:true user:user' }
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ require 'rubocop_spec_helper'
|
|||
require 'rspec-parameterized'
|
||||
require_relative '../../../../rubocop/cop/rspec/have_gitlab_http_status'
|
||||
|
||||
RSpec.describe RuboCop::Cop::RSpec::HaveGitlabHttpStatus do
|
||||
RSpec.describe RuboCop::Cop::RSpec::HaveGitlabHttpStatus, feature_category: :tooling do
|
||||
using RSpec::Parameterized::TableSyntax
|
||||
|
||||
let(:source_file) { 'spec/foo_spec.rb' }
|
||||
|
|
|
|||
|
|
@ -5763,10 +5763,10 @@ dommatrix@^1.0.3:
|
|||
resolved "https://registry.yarnpkg.com/dommatrix/-/dommatrix-1.0.3.tgz#e7c18e8d6f3abdd1fef3dd4aa74c4d2e620a0525"
|
||||
integrity sha512-l32Xp/TLgWb8ReqbVJAFIvXmY7go4nTxxlWiAFyhoQw9RKEOHBZNnyGvJWqDVSPmq3Y9HlM4npqF/T6VMOXhww==
|
||||
|
||||
dompurify@^3.0.11, dompurify@^3.0.5:
|
||||
version "3.0.11"
|
||||
resolved "https://registry.yarnpkg.com/dompurify/-/dompurify-3.0.11.tgz#c163f5816eaac6aeef35dae2b77fca0504564efe"
|
||||
integrity sha512-Fan4uMuyB26gFV3ovPoEoQbxRRPfTu3CvImyZnhGq5fsIEO+gEFLp45ISFt+kQBWsK5ulDdT0oV28jS1UrwQLg==
|
||||
dompurify@^3.0.5, dompurify@^3.1.0:
|
||||
version "3.1.0"
|
||||
resolved "https://registry.yarnpkg.com/dompurify/-/dompurify-3.1.0.tgz#8c6b9fe986969a33aa4686bd829cbe8e14dd9445"
|
||||
integrity sha512-yoU4rhgPKCo+p5UrWWWNKiIq+ToGqmVVhk0PmMYBK4kRsR3/qhemNFL8f6CFmBd4gMwm3F4T7HBoydP5uY07fA==
|
||||
|
||||
dropzone@^4.2.0:
|
||||
version "4.2.0"
|
||||
|
|
|
|||
Loading…
Reference in New Issue