Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
d9749000e7
commit
cf77519fac
|
|
@ -31,67 +31,27 @@ module Ci
|
|||
|
||||
# Fetch all pipelines without permission check.
|
||||
def all
|
||||
::Gitlab::Database.allow_cross_joins_across_databases(url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/336891') do
|
||||
strong_memoize(:all_pipelines) do
|
||||
next Ci::Pipeline.none unless source_project
|
||||
strong_memoize(:all_pipelines) do
|
||||
next Ci::Pipeline.none unless source_project
|
||||
|
||||
pipelines =
|
||||
if merge_request.persisted?
|
||||
all_pipelines_for_merge_request
|
||||
else
|
||||
triggered_for_branch.for_sha(commit_shas)
|
||||
end
|
||||
pipelines =
|
||||
if merge_request.persisted?
|
||||
all_pipelines_for_merge_request
|
||||
else
|
||||
triggered_for_branch.for_sha(commit_shas)
|
||||
end
|
||||
|
||||
pipelines = pipelines.allow_cross_joins_across_databases(url: 'https://gitlab.com/gitlab-org/gitlab/-/issues/336891')
|
||||
|
||||
sort(pipelines)
|
||||
end
|
||||
sort(pipelines)
|
||||
end
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
# rubocop: disable CodeReuse/ActiveRecord
|
||||
def pipelines_using_cte
|
||||
sha_relation = merge_request.all_commits.select(:sha).distinct
|
||||
|
||||
cte = Gitlab::SQL::CTE.new(:shas, sha_relation)
|
||||
|
||||
pipelines_for_merge_requests = triggered_by_merge_request
|
||||
pipelines_for_branch = filter_by_sha(triggered_for_branch, cte)
|
||||
|
||||
Ci::Pipeline.with(cte.to_arel) # rubocop: disable CodeReuse/ActiveRecord
|
||||
.from_union([pipelines_for_merge_requests, pipelines_for_branch])
|
||||
end
|
||||
# rubocop: enable CodeReuse/ActiveRecord
|
||||
|
||||
def filter_by_sha(pipelines, cte)
|
||||
hex = Arel::Nodes::SqlLiteral.new("'hex'")
|
||||
string_sha = Arel::Nodes::NamedFunction.new('encode', [cte.table[:sha], hex])
|
||||
join_condition = string_sha.eq(Ci::Pipeline.arel_table[:sha])
|
||||
|
||||
filter_by(pipelines, cte, join_condition)
|
||||
end
|
||||
|
||||
def filter_by(pipelines, cte, join_condition)
|
||||
shas_table =
|
||||
Ci::Pipeline.arel_table
|
||||
.join(cte.table, Arel::Nodes::InnerJoin)
|
||||
.on(join_condition)
|
||||
.join_sources
|
||||
|
||||
pipelines.joins(shas_table) # rubocop: disable CodeReuse/ActiveRecord
|
||||
end
|
||||
|
||||
def all_pipelines_for_merge_request
|
||||
if Feature.enabled?(:decomposed_ci_query_in_pipelines_for_merge_request_finder, target_project, default_enabled: :yaml)
|
||||
pipelines_for_merge_request = triggered_by_merge_request
|
||||
pipelines_for_branch = triggered_for_branch.for_sha(recent_diff_head_shas(COMMITS_LIMIT))
|
||||
pipelines_for_merge_request = triggered_by_merge_request
|
||||
pipelines_for_branch = triggered_for_branch.for_sha(recent_diff_head_shas(COMMITS_LIMIT))
|
||||
|
||||
Ci::Pipeline.from_union([pipelines_for_merge_request, pipelines_for_branch])
|
||||
else
|
||||
pipelines_using_cte
|
||||
end
|
||||
Ci::Pipeline.from_union([pipelines_for_merge_request, pipelines_for_branch])
|
||||
end
|
||||
|
||||
# NOTE: this method returns only parent merge request pipelines.
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
name: decomposed_ci_query_in_pipelines_for_merge_request_finder
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68549
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/341341
|
||||
milestone: '14.4'
|
||||
type: development
|
||||
group: group::pipeline execution
|
||||
default_enabled: false
|
||||
|
|
@ -6,29 +6,81 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Compliance features **(FREE)**
|
||||
|
||||
You can configure the following GitLab features to help ensure that your GitLab
|
||||
instance meets common compliance standards. Click a feature name for additional
|
||||
documentation.
|
||||
These GitLab features can help ensure that your GitLab instance meets common compliance standards. For more information
|
||||
about compliance management, see the compliance management [solutions page](https://about.gitlab.com/solutions/compliance/).
|
||||
|
||||
The [security features](../security/index.md) in GitLab may also help you meet
|
||||
relevant compliance standards.
|
||||
The [security features](../security/index.md) in GitLab may also help you meet relevant compliance standards.
|
||||
|
||||
| Feature | GitLab tier | GitLab SaaS | Product level |
|
||||
|----------|:-----------:|:-----------:|:-------------:|
|
||||
|**[Restrict SSH Keys](../security/ssh_keys_restrictions.md)**<br>Control the technology and key length of SSH keys used to access GitLab. | Free+ | **{dotted-circle}** No | Instance |
|
||||
|**[Granular user roles and flexible permissions](../user/permissions.md)**<br>Manage access and permissions with five different user roles and settings for external users. Set permissions according to people's role, rather than either read or write access to a repository. Don't share the source code with people that only need access to the issue tracker. | Free+ | **{check-circle}** Yes | Instance, Group, Project |
|
||||
|**[Generate reports on permission levels of users](../user/admin_area/index.md#user-permission-export)**<br>Administrators can generate a report listing all users' access permissions for groups and projects in the instance. | Premium+ | **{dotted-circle}** No | Instance |
|
||||
|**[Enforce TOS acceptance](../user/admin_area/settings/terms.md)**<br>Enforce your users accepting new terms of service by blocking GitLab traffic. | Free+ | **{dotted-circle}** No | Instance |
|
||||
|**[Email all users of a project, group, or entire server](../tools/email.md)**<br>An administrator can email groups of users based on project or group membership, or email everyone using the GitLab instance. This is great for scheduled maintenance or upgrades. | Premium+ | **{dotted-circle}** No | Instance |
|
||||
|**[Omnibus package supports log forwarding](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)**<br>Forward your logs to a central system. | Premium+ | **{dotted-circle}** No | Instance |
|
||||
|**[Lock project membership to group](../user/group/index.md#prevent-members-from-being-added-to-a-group)**<br>Group owners can prevent new members from being added to projects within a group. | Premium+ | **{check-circle}** Yes | Group |
|
||||
|**[LDAP group sync](auth/ldap/ldap_synchronization.md#group-sync)**<br>GitLab Enterprise Edition gives administrators the ability to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools. | Premium+ | **{dotted-circle}** No | Instance |
|
||||
|**[LDAP group sync filters](auth/ldap/ldap_synchronization.md#group-sync)**<br>GitLab Enterprise Edition Premium gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions. | Premium+ | **{dotted-circle}** No | Instance |
|
||||
|**[Audit events](audit_events.md)**<br>To maintain the integrity of your code, GitLab Enterprise Edition Premium gives administrators the ability to view any modifications made within the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. | Premium+ | **{check-circle}** Yes | Instance, Group, Project |
|
||||
|**[Auditor users](auditor_users.md)**<br>Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance. | Premium+ | **{dotted-circle}** No | Instance |
|
||||
|**[Credentials inventory](../user/admin_area/credentials_inventory.md)**<br>With a credentials inventory, GitLab administrators can keep track of the credentials used by all of the users in their GitLab instance. | Ultimate | **{dotted-circle}** No | Instance |
|
||||
|**Separation of Duties using [Protected branches](../user/project/protected_branches.md#require-code-owner-approval-on-a-protected-branch) and [custom CI Configuration Paths](../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file)**<br> GitLab Premium users can leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code. View the [Separation of Duties Deploy Project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md) and [Separation of Duties Project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md) to see how to use this set up to define these roles. | Premium+ | **{check-circle}** Yes | Project |
|
||||
|**[Compliance frameworks](../user/project/settings/index.md#compliance-frameworks)**<br>Create a custom compliance framework at the group level to describe the type of compliance requirements any child project needs to follow. | Premium+ | **{check-circle}** Yes | Group |
|
||||
|**[Compliance pipelines](../user/project/settings/index.md#compliance-pipeline-configuration)**<br>Define a pipeline configuration to run for any projects with a given compliance framework. | Ultimate | **{check-circle}** Yes | Group |
|
||||
|**[Compliance report](../user/compliance/compliance_report/index.md)**<br>Quickly get visibility into the compliance posture of your organization. | Ultimate | **{check-circle}** Yes | Group |
|
||||
|**[External Status Checks](../user/project/merge_requests/status_checks.md)**<br>Interface with third party systems you already use during development to ensure you remain compliant. | Ultimate | **{check-circle}** Yes | Project |
|
||||
## Policy management
|
||||
|
||||
Organizations have unique policy requirements, either due to organizational standards or mandates from regulatory bodies.
|
||||
The following features help you define rules and policies to adhere to workflow requirements, separation of duties, and
|
||||
secure supply chain best practices:
|
||||
|
||||
- [**Credentials inventory**](../user/admin_area/credentials_inventory.md) (for instances): With a credentials inventory,
|
||||
GitLab administrators can keep track of the credentials used by all of the users in their GitLab instance.
|
||||
- [**Granular user roles and flexible permissions**](../user/permissions.md) (for instances, groups, and projects): Manage
|
||||
access and permissions with five different user roles and settings for external users. Set permissions according to people's
|
||||
role, rather than either read or write access to a repository. Don't share the source code with people that only need
|
||||
access to the issue tracker.
|
||||
- [**Merge request approvals**](../user/project/merge_requests/approvals/index.md) (for instances, groups, and projects):
|
||||
Configure approvals required for merge requests.
|
||||
- [**Push rules**](../push_rules/push_rules.md) (for instances, groups, and projects): Control pushes to your
|
||||
repositories.
|
||||
- Separation of duties using [**protected branches**](../user/project/protected_branches.md#require-code-owner-approval-on-a-protected-branch)
|
||||
and [**custom CI/CD configuration paths**](../ci/pipelines/settings.md#specify-a-custom-cicd-configuration-file) (for projects):
|
||||
Users can leverage the GitLab cross-project YAML configurations to define deployers of code and developers of code.
|
||||
See how to use this setup to define these roles in:
|
||||
- The [Separation of Duties deploy project](https://gitlab.com/guided-explorations/separation-of-duties-deploy/blob/master/README.md).
|
||||
- The [Separation of Duties project](https://gitlab.com/guided-explorations/separation-of-duties/blob/master/README.md).
|
||||
|
||||
## Compliant workflow automation
|
||||
|
||||
It is important for compliance teams to be confident that their controls and requirements are set up correctly, but also that they _stay_ set up correctly. One way of doing this is manually checking settings periodically, but this is error prone and time consuming. A better approach is to use single-source-of-truth settings and automation to ensure that whatever a compliance team has configured, stays configured and working correctly. These features can help you automate compliance:
|
||||
|
||||
- [**Compliance frameworks**](../user/project/settings/index.md#compliance-frameworks) (for groups): Create a custom
|
||||
compliance framework at the group level to describe the type of compliance requirements any child project needs to follow.
|
||||
- [**Compliance pipelines**](../user/project/settings/index.md#compliance-pipeline-configuration) (for groups): Define a
|
||||
pipeline configuration to run for any projects with a given compliance framework.
|
||||
|
||||
## Audit management
|
||||
|
||||
An important part of any compliance program is being able to go back and understand what happened, when
|
||||
it happened, and who was responsible. This is useful in audit situations as well as for understanding
|
||||
the root cause of issues when they occur. It is useful to have both low-level, raw lists of audit data
|
||||
as well as high-level, summary lists of audit data. Between these two, compliance teams can quickly
|
||||
identify if problems exist and then drill down into the specifics of those issues. These features can help provide visibility into GitLab and audit what is happening:
|
||||
|
||||
- [**Audit events**](audit_events.md) (for instances, groups, and projects): To maintain the integrity of your code,
|
||||
audit events give administrators the ability to view any modifications made within the GitLab
|
||||
server in an advanced audit events system, so you can control, analyze, and track every change.
|
||||
- [**Auditor users**](auditor_users.md) (for instances): Auditor users are users who are given read-only access to all
|
||||
projects, groups, and other resources on the GitLab instance.
|
||||
- [**Compliance report**](../user/compliance/compliance_report/index.md) (for groups): Quickly get visibility into the
|
||||
compliance posture of your organization.
|
||||
|
||||
## Other compliance features
|
||||
|
||||
These features can also help with compliance requirements:
|
||||
|
||||
- [**Email all users of a project, group, or entire server**](../tools/email.md) (for instances): An administrator can
|
||||
email groups of users based on project or group membership, or email everyone using the GitLab instance. These emails
|
||||
are great for scheduled maintenance or upgrades.
|
||||
- [**Enforce ToS acceptance**](../user/admin_area/settings/terms.md) (for instances): Enforce your users accepting new
|
||||
terms of service by blocking GitLab traffic.
|
||||
- [**External Status Checks**](../user/project/merge_requests/status_checks.md) (for projects): Interface with third-party
|
||||
systems you already use during development to ensure you remain compliant.
|
||||
- [**Generate reports on permission levels of users**](../user/admin_area/index.md#user-permission-export) (for
|
||||
instances): Administrators can generate a report listing all users' access permissions for groups and projects in the
|
||||
instance.
|
||||
- [**Lock project membership to group**](../user/group/index.md#prevent-members-from-being-added-to-a-group) (for
|
||||
groups): Group owners can prevent new members from being added to projects within a group.
|
||||
- [**LDAP group sync**](auth/ldap/ldap_synchronization.md#group-sync) (for instances): Gives administrators the ability
|
||||
to automatically sync groups and manage SSH keys, permissions, and authentication, so you can focus on building your
|
||||
product, not configuring your tools.
|
||||
- [**LDAP group sync filters**](auth/ldap/ldap_synchronization.md#group-sync) (for instances): Gives more flexibility to
|
||||
synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.
|
||||
- [**Omnibus GitLab package supports log forwarding**](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-forwarding)
|
||||
(for instances): Forward your logs to a central system.
|
||||
- [**Restrict SSH Keys**](../security/ssh_keys_restrictions.md) (for instances): Control the technology and key length
|
||||
of SSH keys used to access GitLab.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
|
|||
type: reference, howto
|
||||
---
|
||||
|
||||
# Push Rules **(PREMIUM)**
|
||||
# Push rules **(PREMIUM)**
|
||||
|
||||
Gain additional control over what can and can't be pushed to your repository by using
|
||||
regular expressions to reject pushes based on commit contents, branch names or file details.
|
||||
|
|
|
|||
|
|
@ -61,10 +61,15 @@ details.
|
|||
|
||||
## Personal Access Token prefix
|
||||
|
||||
> [Changed](https://gitlab.com/gitlab-org/gitlab/-/issues/342327) in GitLab 14.5. Default prefix added.
|
||||
|
||||
You can set a global prefix for all generated Personal Access Tokens.
|
||||
|
||||
A prefix can help you identify PATs visually, as well as with automation tools.
|
||||
|
||||
NOTE:
|
||||
For GitLab.com and new self-managed instances, the default prefix is `glpat-`.
|
||||
|
||||
### Set a prefix
|
||||
|
||||
Only a GitLab administrator can set the prefix, which is a global setting applied
|
||||
|
|
|
|||
|
|
@ -179,3 +179,11 @@ include:
|
|||
- template: Security/License-Scanning.gitlab-ci.yml # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/License-Scanning.gitlab-ci.yml
|
||||
- template: Security/SAST.gitlab-ci.yml # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml
|
||||
- template: Security/Secret-Detection.gitlab-ci.yml # https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Secret-Detection.gitlab-ci.yml
|
||||
|
||||
# The latest build job generates a dotenv report artifact with a CI_APPLICATION_TAG
|
||||
# that also includes the image digest. This configures Auto Deploy to receive
|
||||
# this artifact and use the updated CI_APPLICATION_TAG for deployments.
|
||||
.auto-deploy:
|
||||
dependencies: [build]
|
||||
dast_environment_deploy:
|
||||
dependencies: [build]
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
# This template is scheduled for removal when testing is complete: https://gitlab.com/gitlab-org/gitlab/-/issues/337987
|
||||
|
||||
variables:
|
||||
AUTO_BUILD_IMAGE_VERSION: 'v1.3.1'
|
||||
AUTO_BUILD_IMAGE_VERSION: 'v1.5.0'
|
||||
|
||||
build:
|
||||
stage: build
|
||||
|
|
@ -23,6 +23,9 @@ build:
|
|||
export CI_APPLICATION_TAG=${CI_APPLICATION_TAG:-$CI_COMMIT_TAG}
|
||||
fi
|
||||
- /build/build.sh
|
||||
artifacts:
|
||||
reports:
|
||||
dotenv: gl-auto-build-variables.env
|
||||
rules:
|
||||
- if: '$BUILD_DISABLED'
|
||||
when: never
|
||||
|
|
|
|||
|
|
@ -135,86 +135,6 @@ RSpec.describe Ci::PipelinesForMergeRequestFinder do
|
|||
end
|
||||
|
||||
context 'when pipelines exist for the branch and merge request' do
|
||||
shared_examples 'returns all pipelines for merge request' do
|
||||
it 'returns merge request pipeline first' do
|
||||
expect(subject.all).to eq([detached_merge_request_pipeline, branch_pipeline])
|
||||
end
|
||||
|
||||
context 'when there are a branch pipeline and a merge request pipeline' do
|
||||
let!(:branch_pipeline_2) do
|
||||
create(:ci_pipeline, source: :push, project: project,
|
||||
ref: source_ref, sha: shas.first)
|
||||
end
|
||||
|
||||
let!(:detached_merge_request_pipeline_2) do
|
||||
create(:ci_pipeline, source: :merge_request_event, project: project,
|
||||
ref: source_ref, sha: shas.first, merge_request: merge_request)
|
||||
end
|
||||
|
||||
it 'returns merge request pipelines first' do
|
||||
expect(subject.all)
|
||||
.to eq([detached_merge_request_pipeline_2,
|
||||
detached_merge_request_pipeline,
|
||||
branch_pipeline_2,
|
||||
branch_pipeline])
|
||||
end
|
||||
end
|
||||
|
||||
context 'when there are multiple merge request pipelines from the same branch' do
|
||||
let!(:branch_pipeline_2) do
|
||||
create(:ci_pipeline, source: :push, project: project,
|
||||
ref: source_ref, sha: shas.first)
|
||||
end
|
||||
|
||||
let!(:branch_pipeline_with_sha_not_belonging_to_merge_request) do
|
||||
create(:ci_pipeline, source: :push, project: project, ref: source_ref)
|
||||
end
|
||||
|
||||
let!(:detached_merge_request_pipeline_2) do
|
||||
create(:ci_pipeline, source: :merge_request_event, project: project,
|
||||
ref: source_ref, sha: shas.first, merge_request: merge_request_2)
|
||||
end
|
||||
|
||||
let(:merge_request_2) do
|
||||
create(:merge_request, source_project: project, source_branch: source_ref,
|
||||
target_project: project, target_branch: 'stable')
|
||||
end
|
||||
|
||||
before do
|
||||
shas.each.with_index do |sha, index|
|
||||
create(:merge_request_diff_commit,
|
||||
merge_request_diff: merge_request_2.merge_request_diff,
|
||||
sha: sha, relative_order: index)
|
||||
end
|
||||
end
|
||||
|
||||
it 'returns only related merge request pipelines' do
|
||||
expect(subject.all)
|
||||
.to eq([detached_merge_request_pipeline,
|
||||
branch_pipeline_2,
|
||||
branch_pipeline])
|
||||
|
||||
expect(described_class.new(merge_request_2, nil).all)
|
||||
.to match_array([detached_merge_request_pipeline_2, branch_pipeline_2, branch_pipeline])
|
||||
end
|
||||
end
|
||||
|
||||
context 'when detached merge request pipeline is run on head ref of the merge request' do
|
||||
let!(:detached_merge_request_pipeline) do
|
||||
create(:ci_pipeline, source: :merge_request_event, project: project,
|
||||
ref: merge_request.ref_path, sha: shas.second, merge_request: merge_request)
|
||||
end
|
||||
|
||||
it 'sets the head ref of the merge request to the pipeline ref' do
|
||||
expect(detached_merge_request_pipeline.ref).to match(%r{refs/merge-requests/\d+/head})
|
||||
end
|
||||
|
||||
it 'includes the detached merge request pipeline even though the ref is custom path' do
|
||||
expect(merge_request.all_pipelines).to include(detached_merge_request_pipeline)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
let(:source_ref) { 'feature' }
|
||||
let(:target_ref) { 'master' }
|
||||
|
||||
|
|
@ -240,20 +160,76 @@ RSpec.describe Ci::PipelinesForMergeRequestFinder do
|
|||
let(:project) { create(:project, :repository) }
|
||||
let(:shas) { project.repository.commits(source_ref, limit: 2).map(&:id) }
|
||||
|
||||
context 'when `decomposed_ci_query_in_pipelines_for_merge_request_finder` feature flag enabled' do
|
||||
before do
|
||||
stub_feature_flags(decomposed_ci_query_in_pipelines_for_merge_request_finder: merge_request.target_project)
|
||||
end
|
||||
|
||||
it_behaves_like 'returns all pipelines for merge request'
|
||||
it 'returns merge request pipeline first' do
|
||||
expect(subject.all).to match_array([detached_merge_request_pipeline, branch_pipeline])
|
||||
end
|
||||
|
||||
context 'when `decomposed_ci_query_in_pipelines_for_merge_request_finder` feature flag disabled' do
|
||||
before do
|
||||
stub_feature_flags(decomposed_ci_query_in_pipelines_for_merge_request_finder: false)
|
||||
context 'when there are a branch pipeline and a merge request pipeline' do
|
||||
let!(:branch_pipeline_2) do
|
||||
create(:ci_pipeline, source: :push, project: project,
|
||||
ref: source_ref, sha: shas.first)
|
||||
end
|
||||
|
||||
it_behaves_like 'returns all pipelines for merge request'
|
||||
let!(:detached_merge_request_pipeline_2) do
|
||||
create(:ci_pipeline, source: :merge_request_event, project: project,
|
||||
ref: source_ref, sha: shas.first, merge_request: merge_request)
|
||||
end
|
||||
|
||||
it 'returns merge request pipelines first' do
|
||||
expect(subject.all)
|
||||
.to match_array([detached_merge_request_pipeline_2, detached_merge_request_pipeline, branch_pipeline_2, branch_pipeline])
|
||||
end
|
||||
end
|
||||
|
||||
context 'when there are multiple merge request pipelines from the same branch' do
|
||||
let!(:branch_pipeline_2) do
|
||||
create(:ci_pipeline, source: :push, project: project,
|
||||
ref: source_ref, sha: shas.first)
|
||||
end
|
||||
|
||||
let!(:branch_pipeline_with_sha_not_belonging_to_merge_request) do
|
||||
create(:ci_pipeline, source: :push, project: project, ref: source_ref)
|
||||
end
|
||||
|
||||
let!(:detached_merge_request_pipeline_2) do
|
||||
create(:ci_pipeline, source: :merge_request_event, project: project,
|
||||
ref: source_ref, sha: shas.first, merge_request: merge_request_2)
|
||||
end
|
||||
|
||||
let(:merge_request_2) do
|
||||
create(:merge_request, source_project: project, source_branch: source_ref,
|
||||
target_project: project, target_branch: 'stable')
|
||||
end
|
||||
|
||||
before do
|
||||
shas.each.with_index do |sha, index|
|
||||
create(:merge_request_diff_commit,
|
||||
merge_request_diff: merge_request_2.merge_request_diff,
|
||||
sha: sha, relative_order: index)
|
||||
end
|
||||
end
|
||||
|
||||
it 'returns only related merge request pipelines' do
|
||||
expect(subject.all).to match_array([detached_merge_request_pipeline, branch_pipeline_2, branch_pipeline])
|
||||
|
||||
expect(described_class.new(merge_request_2, nil).all)
|
||||
.to match_array([detached_merge_request_pipeline_2, branch_pipeline_2, branch_pipeline])
|
||||
end
|
||||
end
|
||||
|
||||
context 'when detached merge request pipeline is run on head ref of the merge request' do
|
||||
let!(:detached_merge_request_pipeline) do
|
||||
create(:ci_pipeline, source: :merge_request_event, project: project,
|
||||
ref: merge_request.ref_path, sha: shas.second, merge_request: merge_request)
|
||||
end
|
||||
|
||||
it 'sets the head ref of the merge request to the pipeline ref' do
|
||||
expect(detached_merge_request_pipeline.ref).to match(%r{refs/merge-requests/\d+/head})
|
||||
end
|
||||
|
||||
it 'includes the detached merge request pipeline even though the ref is custom path' do
|
||||
expect(merge_request.all_pipelines).to include(detached_merge_request_pipeline)
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue