Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
612bb6f624
commit
11cb5f046d
|
|
@ -214,15 +214,15 @@ module Ci
|
|||
Arel.sql("(#{arel_tag_names_array.to_sql})")
|
||||
]
|
||||
|
||||
# we use distinct to de-duplicate data
|
||||
distinct.pluck(*unique_params).map do |values|
|
||||
group(*unique_params).pluck('array_agg(ci_runners.id)', *unique_params).map do |values|
|
||||
Gitlab::Ci::Matching::RunnerMatcher.new({
|
||||
runner_type: values[0],
|
||||
public_projects_minutes_cost_factor: values[1],
|
||||
private_projects_minutes_cost_factor: values[2],
|
||||
run_untagged: values[3],
|
||||
access_level: values[4],
|
||||
tag_list: values[5]
|
||||
runner_ids: values[0],
|
||||
runner_type: values[1],
|
||||
public_projects_minutes_cost_factor: values[2],
|
||||
private_projects_minutes_cost_factor: values[3],
|
||||
run_untagged: values[4],
|
||||
access_level: values[5],
|
||||
tag_list: values[6]
|
||||
})
|
||||
end
|
||||
end
|
||||
|
|
@ -230,6 +230,7 @@ module Ci
|
|||
def runner_matcher
|
||||
strong_memoize(:runner_matcher) do
|
||||
Gitlab::Ci::Matching::RunnerMatcher.new({
|
||||
runner_ids: [id],
|
||||
runner_type: runner_type,
|
||||
public_projects_minutes_cost_factor: public_projects_minutes_cost_factor,
|
||||
private_projects_minutes_cost_factor: private_projects_minutes_cost_factor,
|
||||
|
|
|
|||
|
|
@ -2,8 +2,6 @@
|
|||
|
||||
module Namespaces
|
||||
class InProductMarketingEmailsService
|
||||
include Gitlab::Experimentation::GroupTypes
|
||||
|
||||
TRACKS = {
|
||||
create: {
|
||||
interval_days: [1, 5, 10],
|
||||
|
|
@ -61,12 +59,6 @@ module Namespaces
|
|||
attr_reader :track, :interval, :in_product_marketing_email_records
|
||||
|
||||
def send_email_for_group(group)
|
||||
if Gitlab.com?
|
||||
experiment_enabled_for_group = experiment_enabled_for_group?(group)
|
||||
experiment_add_group(group, experiment_enabled_for_group)
|
||||
return unless experiment_enabled_for_group
|
||||
end
|
||||
|
||||
users_for_group(group).each do |user|
|
||||
if can_perform_action?(user, group)
|
||||
send_email(user, group)
|
||||
|
|
@ -77,15 +69,6 @@ module Namespaces
|
|||
save_tracked_emails!
|
||||
end
|
||||
|
||||
def experiment_enabled_for_group?(group)
|
||||
Gitlab::Experimentation.in_experiment_group?(:in_product_marketing_emails, subject: group)
|
||||
end
|
||||
|
||||
def experiment_add_group(group, experiment_enabled_for_group)
|
||||
variant = experiment_enabled_for_group ? GROUP_EXPERIMENTAL : GROUP_CONTROL
|
||||
Experiment.add_group(:in_product_marketing_emails, variant: variant, group: group)
|
||||
end
|
||||
|
||||
def groups_for_track
|
||||
onboarding_progress_scope = OnboardingProgress
|
||||
.completed_actions_with_latest_in_range(completed_actions, range)
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
- breadcrumb_title _('Integrations')
|
||||
- page_title _('Integrations')
|
||||
- breadcrumb_title s_('Integrations|Instance-level integration management')
|
||||
- page_title s_('Integrations|Instance-level integration management')
|
||||
- @content_class = 'limit-container-width' unless fluid_layout
|
||||
|
||||
%h3= s_('Integrations|Project integration management')
|
||||
%h3= s_('Integrations|Instance-level integration management')
|
||||
|
||||
- integrations_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: integrations_help_page_path }
|
||||
%p= s_("Integrations|GitLab administrators can set up integrations that all projects inherit and use by default. These integrations apply to all projects that don't already use custom settings. You can override custom settings for a group or project if the settings are necessary at that level. Learn more about %{integrations_link_start}project integration management%{link_end}.").html_safe % { integrations_link_start: integrations_link_start, link_end: "</a>".html_safe }
|
||||
%p= s_("Integrations|GitLab administrators can set up integrations that all groups and projects inherit and use by default. These integrations apply to all groups and projects that don't already use custom settings. You can override custom settings for a group or project if the settings are necessary at that level. Learn more about %{integrations_link_start}instance-level integration management%{link_end}.").html_safe % { integrations_link_start: integrations_link_start, link_end: "</a>".html_safe }
|
||||
= render 'shared/integrations/index', integrations: @integrations
|
||||
|
|
|
|||
|
|
@ -19,7 +19,8 @@
|
|||
path: admin_user_impersonation_tokens_path,
|
||||
impersonation: true,
|
||||
token: @impersonation_token,
|
||||
scopes: @scopes
|
||||
scopes: @scopes,
|
||||
help_path: help_page_path('api/README', anchor: 'impersonation-tokens')
|
||||
|
||||
= render 'shared/access_tokens/table',
|
||||
type: type,
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
- breadcrumb_title _('Integrations')
|
||||
- page_title _('Integrations')
|
||||
- breadcrumb_title s_('Integrations|Group-level integration management')
|
||||
- page_title s_('Integrations|Group-level integration management')
|
||||
- @content_class = 'limit-container-width' unless fluid_layout
|
||||
|
||||
%h3= s_('Integrations|Project integration management')
|
||||
%h3= s_('Integrations|Group-level integration management')
|
||||
|
||||
- integrations_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: integrations_help_page_path }
|
||||
%p= s_("Integrations|GitLab administrators can set up integrations that all projects inherit and use by default. These integrations apply to all projects that don't already use custom settings. You can override custom settings for a group or project if the settings are necessary at that level. Learn more about %{integrations_link_start}project integration management%{link_end}.").html_safe % { integrations_link_start: integrations_link_start, link_end: "</a>".html_safe }
|
||||
%p= s_("Integrations|GitLab administrators can set up integrations that all projects in a group inherit and use by default. These integrations apply to all projects that don't already use custom settings. You can override custom settings for a project if the settings are necessary at that level. Learn more about %{integrations_link_start}group-level integration management%{link_end}.").html_safe % { integrations_link_start: integrations_link_start, link_end: "</a>".html_safe }
|
||||
= render 'shared/integrations/index', integrations: @integrations
|
||||
|
|
|
|||
|
|
@ -24,7 +24,8 @@
|
|||
type: type,
|
||||
path: profile_personal_access_tokens_path,
|
||||
token: @personal_access_token,
|
||||
scopes: @scopes
|
||||
scopes: @scopes,
|
||||
help_path: help_page_path('user/profile/personal_access_tokens.md', anchor: 'personal-access-token-scopes')
|
||||
|
||||
= render 'shared/access_tokens/table',
|
||||
type: type,
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
.col-md-10
|
||||
= render partial: "projects/protected_branches/shared/dropdown", locals: { f: f }
|
||||
.form-text.text-muted
|
||||
- wildcards_url = help_page_url('user/project/protected_branches', anchor: 'wildcard-protected-branches')
|
||||
- wildcards_url = help_page_url('user/project/protected_branches', anchor: 'configure-multiple-protected-branches-by-using-a-wildcard')
|
||||
- wildcards_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: wildcards_url }
|
||||
= (s_("ProtectedBranch|%{wildcards_link_start}Wildcards%{wildcards_link_end} such as %{code_tag_start}*-stable%{code_tag_end} or %{code_tag_start}production/*%{code_tag_end} are supported.") % { wildcards_link_start: wildcards_link_start, wildcards_link_end: '</a>', code_tag_start: '<code>', code_tag_end: '</code>' }).html_safe
|
||||
.form-group.row
|
||||
|
|
|
|||
|
|
@ -35,7 +35,8 @@
|
|||
path: project_settings_access_tokens_path(@project),
|
||||
token: @project_access_token,
|
||||
scopes: @scopes,
|
||||
prefix: :project_access_token
|
||||
prefix: :project_access_token,
|
||||
help_path: help_page_path('user/project/settings/project_access_tokens', anchor: 'limiting-scopes-of-a-project-access-token')
|
||||
|
||||
= render 'shared/access_tokens/table',
|
||||
active_tokens: @active_project_access_tokens,
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
- title = local_assigns.fetch(:title, _('Add a %{type}') % { type: type })
|
||||
- prefix = local_assigns.fetch(:prefix, :personal_access_token)
|
||||
- help_path = local_assigns.fetch(:help_path)
|
||||
|
||||
%h5.gl-mt-0
|
||||
= title
|
||||
|
|
@ -11,13 +12,16 @@
|
|||
= form_errors(token)
|
||||
|
||||
.row
|
||||
.form-group.col-md-6
|
||||
= f.label :name, _('Name'), class: 'label-bold'
|
||||
= f.text_field :name, class: 'form-control gl-form-input', required: true, data: { qa_selector: 'access_token_name_field' }
|
||||
.form-group.col
|
||||
.row
|
||||
= f.label :name, _('Token name'), class: 'label-bold col-md-12'
|
||||
.col-md-6
|
||||
= f.text_field :name, class: 'form-control gl-form-input', required: true, data: { qa_selector: 'access_token_name_field' }, :'aria-describedby' => 'access_token_help_text'
|
||||
%span.form-text.text-muted.col-md-12#access_token_help_text= _('For example, the application using the token or the purpose of the token.')
|
||||
|
||||
.row
|
||||
.form-group.col-md-6
|
||||
= f.label :expires_at, _('Expires at'), class: 'label-bold'
|
||||
= f.label :expires_at, _('Expiration date'), class: 'label-bold'
|
||||
.input-icon-wrapper
|
||||
|
||||
= render_if_exists 'personal_access_tokens/callout_max_personal_access_token_lifetime'
|
||||
|
|
@ -26,7 +30,11 @@
|
|||
= f.text_field :expires_at, class: 'datepicker gl-datepicker-input form-control gl-form-input', placeholder: 'YYYY-MM-DD', autocomplete: 'off', data: { js_name: 'expiresAt' }
|
||||
|
||||
.form-group
|
||||
= f.label :scopes, _('Scopes'), class: 'label-bold'
|
||||
%b{ :'aria-describedby' => 'select_scope_help_text' }
|
||||
= s_('Tokens|Select scopes')
|
||||
%p.text-secondary#select_scope_help_text
|
||||
= s_('Tokens|Scopes set the permission levels granted to the token.')
|
||||
= link_to "Learn more.", help_path, target: '_blank'
|
||||
= render 'shared/tokens/scopes_form', prefix: prefix, token: token, scopes: scopes
|
||||
|
||||
- if prefix == :personal_access_token && Feature.enabled?(:personal_access_tokens_scoped_to_projects, current_user)
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
%table.table.active-tokens
|
||||
%thead
|
||||
%tr
|
||||
%th= _('Name')
|
||||
%th= _('Token name')
|
||||
%th= s_('AccessTokens|Created')
|
||||
%th
|
||||
= _('Last Used')
|
||||
|
|
|
|||
|
|
@ -14,7 +14,6 @@ module Namespaces
|
|||
def perform
|
||||
return if paid_self_managed_instance?
|
||||
return if setting_disabled?
|
||||
return if experiment_inactive?
|
||||
|
||||
Namespaces::InProductMarketingEmailsService.send_for_all_tracks_and_intervals
|
||||
end
|
||||
|
|
@ -28,10 +27,6 @@ module Namespaces
|
|||
def setting_disabled?
|
||||
!Gitlab::CurrentSettings.in_product_marketing_emails_enabled
|
||||
end
|
||||
|
||||
def experiment_inactive?
|
||||
Gitlab.com? && !Gitlab::Experimentation.active?(:in_product_marketing_emails)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
name: in_product_marketing_emails_experiment_percentage
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50679
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/growth/team-tasks/-/issues/303
|
||||
milestone: "13.9"
|
||||
type: experiment
|
||||
group: group::activation
|
||||
default_enabled: false
|
||||
|
|
@ -26,7 +26,7 @@ relevant compliance standards.
|
|||
|**[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#protected-branches-approval-by-code-owners) and [custom CI Configuration Paths](../ci/pipelines/settings.md#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 |
|
||||
|**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#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 dashboard](../user/compliance/compliance_dashboard/index.md)**<br>Quickly get visibility into the compliance posture of your organization. | Ultimate | **{check-circle}** Yes | Group |
|
||||
|
|
|
|||
|
|
@ -6,22 +6,24 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# API Docs **(FREE)**
|
||||
|
||||
Use the GitLab [REST](http://spec.openapis.org/oas/v3.0.3) API to automate GitLab.
|
||||
Use the GitLab APIs to automate GitLab.
|
||||
|
||||
You can also use a partial [OpenAPI definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/api/openapi/openapi.yaml),
|
||||
to test the API directly from the GitLab user interface.
|
||||
Contributions are welcome.
|
||||
|
||||
## Available API resources
|
||||
## REST API
|
||||
|
||||
A REST API is available in GitLab.
|
||||
Usage instructions are below.
|
||||
For a list of the available resources and their endpoints, see
|
||||
[API resources](api_resources.md).
|
||||
[REST API resources](api_resources.md).
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an introduction and basic steps, see
|
||||
[How to make GitLab API calls](https://www.youtube.com/watch?v=0LsMC3ZiXkA).
|
||||
|
||||
## SCIM **(PREMIUM SAAS)**
|
||||
## SCIM API **(PREMIUM SAAS)**
|
||||
|
||||
GitLab provides an [SCIM API](scim.md) that both implements
|
||||
[the RFC7644 protocol](https://tools.ietf.org/html/rfc7644) and provides the
|
||||
|
|
@ -29,7 +31,7 @@ GitLab provides an [SCIM API](scim.md) that both implements
|
|||
|
||||
## GraphQL API
|
||||
|
||||
A [GraphQL](graphql/index.md) API is available in GitLab.
|
||||
A [GraphQL API](graphql/index.md) is available in GitLab.
|
||||
|
||||
With GraphQL, you can make an API request for only what you need,
|
||||
and it's versioned by default.
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@ group: Ecosystem
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# API resources **(FREE)**
|
||||
# REST API resources **(FREE)**
|
||||
|
||||
Available resources for the [GitLab API](README.md) can be grouped in the following contexts:
|
||||
Available resources for the [GitLab REST API](README.md) can be grouped in the following contexts:
|
||||
|
||||
- [Projects](#project-resources).
|
||||
- [Groups](#group-resources).
|
||||
|
|
|
|||
|
|
@ -280,7 +280,7 @@ Example response:
|
|||
### Example with user / group level access **(PREMIUM)**
|
||||
|
||||
Elements in the `allowed_to_push` / `allowed_to_merge` / `allowed_to_unprotect` array should take the
|
||||
form `{user_id: integer}`, `{group_id: integer}` or `{access_level: integer}`. Each user must have access to the project and each group must [have this project shared](../user/project/members/share_project_with_groups.md). These access levels allow [more granular control over protected branch access](../user/project/protected_branches.md#restricting-push-and-merge-access-to-certain-users) and were [added to the API](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3516) in GitLab 10.3 EE.
|
||||
form `{user_id: integer}`, `{group_id: integer}`, or `{access_level: integer}`. Each user must have access to the project and each group must [have this project shared](../user/project/members/share_project_with_groups.md). These access levels allow [more granular control over protected branch access](../user/project/protected_branches.md).
|
||||
|
||||
```shell
|
||||
curl --request POST --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/protected_branches?name=*-stable&allowed_to_push%5B%5D%5Buser_id%5D=1"
|
||||
|
|
|
|||
|
|
@ -301,7 +301,7 @@ A strict security model is enforced when pipelines are executed on
|
|||
[protected branches](../../user/project/protected_branches.md).
|
||||
|
||||
The following actions are allowed on protected branches only if the user is
|
||||
[allowed to merge or push](../../user/project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
|
||||
[allowed to merge or push](../../user/project/protected_branches.md)
|
||||
on that specific branch:
|
||||
|
||||
- Run manual pipelines (using the [Web UI](#run-a-pipeline-manually) or [pipelines API](#pipelines-api)).
|
||||
|
|
|
|||
|
|
@ -117,6 +117,8 @@ test its execution using `CREATE INDEX CONCURRENTLY` in the `#database-lab` Slac
|
|||
- If the execution from `#database-lab` is longer than `1h`, the index should be moved to a [post-migration](post_deployment_migrations.md).
|
||||
Keep in mind that in this case you may need to split the migration and the application changes in separate releases to ensure the index
|
||||
will be in place when the code that needs it will be deployed.
|
||||
- Trigger the [database testing](../architecture/blueprints/database_testing/index.md) job (`db:gitlabcom-database-testing`) in the `test` stage.
|
||||
- Review migration runtimes and any warnings.
|
||||
|
||||
#### Preparation when adding or modifying queries
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ the tiers are no longer mentioned in GitLab documentation:
|
|||
- [Required Approvals](../user/project/merge_requests/approvals/index.md#required-approvals)
|
||||
- [Code Owners as eligible approvers](../user/project/merge_requests/approvals/rules.md#code-owners-as-eligible-approvers)
|
||||
- [Approval rules](../user/project/merge_requests/approvals/rules.md) features
|
||||
- [Restricting push and merge access to certain users](../user/project/protected_branches.md#restricting-push-and-merge-access-to-certain-users)
|
||||
- [Restricting push and merge access to certain users](../user/project/protected_branches.md)
|
||||
- [Visual Reviews](../ci/review_apps/index.md#visual-reviews)
|
||||
- Metrics and analytics:
|
||||
- [Contribution Analytics](../user/group/contribution_analytics/index.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
---
|
||||
stage: Configure
|
||||
group: Configure
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# CI/CD Tunnel
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327409) in GitLab 14.0.
|
||||
|
||||
The CI/CD Tunnel enables users to access Kubernetes clusters from GitLab CI/CD jobs even if there is no network
|
||||
connectivity between GitLab Runner and a cluster. In the current iteration, only CI/CD jobs in the Configuration project
|
||||
are able to access one of the configured agents. GitLab Runner does not have to be running in the same cluster.
|
||||
|
||||
Prerequisistes:
|
||||
|
||||
- A running [`kas` instance](index.md#set-up-the-kubernetes-agent-server).
|
||||
- A [Configuration repository](index.md#define-a-configuration-repository) with an Agent config file installed (`.gitlab/agents/<agent-name>/config.yaml`).
|
||||
- An [Agent record](index.md#create-an-agent-record-in-gitlab).
|
||||
- The agent is [installed in the cluster](index.md#install-the-agent-into-the-cluster).
|
||||
|
||||
To create the Tunnel:
|
||||
|
||||
1. In your `.gitlab-ci.yml` add a section that creates a `kubectl` compatible configuration file and use it in one
|
||||
or more jobs:
|
||||
|
||||
```yaml
|
||||
variables:
|
||||
AGENT_ID: 4 # agent id that you got when you created the agent record
|
||||
|
||||
.kubectl_config: &kubectl_config
|
||||
- |
|
||||
cat << EOF > "$HOME/agent_config.yaml"
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
clusters:
|
||||
- cluster:
|
||||
server: https://kas.gitlab.com/k8s-proxy
|
||||
name: agent
|
||||
users:
|
||||
- name: agent
|
||||
user:
|
||||
token: "ci:$AGENT_ID:$CI_JOB_TOKEN"
|
||||
contexts:
|
||||
- context:
|
||||
cluster: agent
|
||||
user: agent
|
||||
name: agent
|
||||
current-context: agent
|
||||
EOF
|
||||
- export KUBECONFIG="$KUBECONFIG:$HOME/agent_config.yaml"
|
||||
|
||||
deploy:
|
||||
script:
|
||||
- *kubectl_config
|
||||
- kubectl get pods
|
||||
```
|
||||
|
||||
1. Execute `kubectl` commands directly against your cluster with this CI/CD job you just created.
|
||||
|
||||
We are [working to automate the first step](https://gitlab.com/gitlab-org/gitlab/-/issues/324275) to simplify the process.
|
||||
|
|
@ -20,6 +20,7 @@ tasks in a secure and cloud-native way. It enables:
|
|||
[GitOps Engine](https://github.com/argoproj/gitops-engine).
|
||||
- Real-time access to API endpoints in a cluster.
|
||||
- Alert generation based on [Container network policy](../../application_security/threat_monitoring/index.md#container-network-policy).
|
||||
- [CI/CD Tunnel](ci_cd_tunnel.md) that enables users to access Kubernetes clusters from GitLab CI/CD jobs even if there is no network connectivity between GitLab Runner and a cluster.
|
||||
|
||||
Many more features are planned. Please review [our roadmap](https://gitlab.com/groups/gitlab-org/-/epics/3329)
|
||||
and [our development documentation](../../../development/agent/index.md).
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ need, or even add new ones that are not built-in.
|
|||
1. Create a new project, choosing "GitLab Cluster Management" from the list of [built-in project templates](../project/working_with_projects.md#built-in-templates).
|
||||
1. Make this project a [cluster management project](management_project.md).
|
||||
1. If you used the [GitLab Managed Apps](applications.md), refer to
|
||||
[Migrating from GitLab Manged Apps](migrating_from_gma_to_project_template.md).
|
||||
[Migrating from GitLab Managed Apps](migrating_from_gma_to_project_template.md).
|
||||
|
||||
### Components
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ GitLab, and support Terraform best practices.
|
|||
## Quick Start
|
||||
|
||||
Use the following `.gitlab-ci.yml` to set up a basic Terraform project integration
|
||||
for GitLab versions 13.5 and later:
|
||||
for GitLab versions 14.0 and later:
|
||||
|
||||
```yaml
|
||||
include:
|
||||
|
|
|
|||
|
|
@ -195,7 +195,7 @@ The following table lists project permissions available for each role:
|
|||
1. Guest users can only view the confidential issues they created themselves.
|
||||
1. If **Public pipelines** is enabled in **Project Settings > CI/CD**.
|
||||
1. Not allowed for Guest, Reporter, Developer, Maintainer, or Owner. See [protected branches](project/protected_branches.md).
|
||||
1. If the [branch is protected](project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings), this depends on the access Developers and Maintainers are given.
|
||||
1. If the [branch is protected](project/protected_branches.md), this depends on the access Developers and Maintainers are given.
|
||||
1. Guest users can access GitLab [**Releases**](project/releases/index.md) for downloading assets but are not allowed to download the source code nor see repository information like tags and commits.
|
||||
1. Actions are limited only to records owned (referenced) by user.
|
||||
1. When [Share Group Lock](group/index.md#prevent-a-project-from-being-shared-with-groups) is enabled the project can't be shared with other groups. It does not affect group with group sharing.
|
||||
|
|
@ -223,7 +223,7 @@ which visibility level you select on project settings.
|
|||
Additional restrictions can be applied on a per-branch basis with [protected branches](project/protected_branches.md).
|
||||
Additionally, you can customize permissions to allow or prevent project
|
||||
Maintainers and Developers from pushing to a protected branch. Read through the documentation on
|
||||
[Allowed to Merge and Allowed to Push settings](project/protected_branches.md#using-the-allowed-to-merge-and-allowed-to-push-settings)
|
||||
[protected branches](project/protected_branches.md)
|
||||
to learn more.
|
||||
|
||||
### Value Stream Analytics permissions
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
|
|
@ -322,7 +322,7 @@ being executed which deploys each function as a Knative service. After the
|
|||
deploy stage has finished, additional details for the function display
|
||||
under **Infrastructure > Serverless platform**.
|
||||
|
||||
|
||||
|
||||
|
||||
This page contains all functions available for the project, the description for
|
||||
accessing the function, and, if available, the function's runtime information.
|
||||
|
|
@ -463,7 +463,7 @@ Go to the **Infrastructure > Serverless platform** page to see the final URL of
|
|||
On the same page as above, click on one of the function
|
||||
rows to bring up the function details page.
|
||||
|
||||
|
||||
|
||||
|
||||
The pod count gives you the number of pods running the serverless function instances on a given cluster.
|
||||
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ After you've added Code Owners to a project, you can configure it to
|
|||
be used for merge request approvals:
|
||||
|
||||
- As [merge request eligible approvers](merge_requests/approvals/rules.md#code-owners-as-eligible-approvers).
|
||||
- As required approvers for [protected branches](protected_branches.md#protected-branches-approval-by-code-owners). **(PREMIUM)**
|
||||
- As required approvers for [protected branches](protected_branches.md#require-code-owner-approval-on-a-protected-branch). **(PREMIUM)**
|
||||
|
||||
Developer or higher [permissions](../permissions.md) are required to
|
||||
approve a merge request.
|
||||
|
|
@ -93,11 +93,11 @@ without using [Approval Rules](merge_requests/approvals/rules.md):
|
|||
|
||||
1. Create the file in one of the three locations specified above.
|
||||
1. Set the code owners as required approvers for
|
||||
[protected branches](protected_branches.md#protected-branches-approval-by-code-owners).
|
||||
[protected branches](protected_branches.md#require-code-owner-approval-on-a-protected-branch).
|
||||
1. Use [the syntax of Code Owners files](code_owners.md#the-syntax-of-code-owners-files)
|
||||
to specify the actual owners and granular permissions.
|
||||
|
||||
Using Code Owners in conjunction with [protected branches](protected_branches.md#protected-branches-approval-by-code-owners)
|
||||
Using Code Owners in conjunction with [protected branches](protected_branches.md#require-code-owner-approval-on-a-protected-branch)
|
||||
prevents any user who is not specified in the `CODEOWNERS` file from pushing
|
||||
changes for the specified files/paths, except those included in the
|
||||
**Allowed to push** column. This allows for a more inclusive push strategy, as
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.0 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.2 KiB |
|
|
@ -159,7 +159,7 @@ become eligible approvers in the project. To enable this merge request approval
|
|||
|
||||
|
||||
You can also
|
||||
[require code owner approval](../../protected_branches.md#protected-branches-approval-by-code-owners)
|
||||
[require code owner approval](../../protected_branches.md#require-code-owner-approval-on-a-protected-branch)
|
||||
for protected branches. **(PREMIUM)**
|
||||
|
||||
## Merge request approval segregation of duties **(PREMIUM)**
|
||||
|
|
@ -229,4 +229,4 @@ approval rule for certain branches:
|
|||
|
||||
|
||||
1. To enable this configuration, read
|
||||
[Code Owner's approvals for protected branches](../../protected_branches.md#protected-branches-approval-by-code-owners).
|
||||
[Code Owner's approvals for protected branches](../../protected_branches.md#require-code-owner-approval-on-a-protected-branch).
|
||||
|
|
|
|||
|
|
@ -25,12 +25,12 @@ these restrictions on the branch.
|
|||
| Force push to the branch | No one. |
|
||||
| Delete the branch | No one. |
|
||||
|
||||
(*) Users with developer permissions can create a project in a group,
|
||||
(*) Users with the Developer role can create a project in a group,
|
||||
but might not be allowed to initially push to the [default branch](repository/branches/default.md).
|
||||
|
||||
### Set the branch protection default level
|
||||
### Set the default branch protection level
|
||||
|
||||
The default branch protection level is set in the [Admin Area](../admin_area/settings/visibility_and_access_controls.md#default-branch-protection).
|
||||
Administrators can set a default branch protection level in the [Admin Area](../admin_area/settings/visibility_and_access_controls.md#default-branch-protection).
|
||||
|
||||
## Configure a protected branch
|
||||
|
||||
|
|
@ -43,140 +43,108 @@ To protect a branch:
|
|||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. From the **Branch** dropdown menu, select the branch you want to protect.
|
||||
1. From the **Allowed to merge** list, select a role, or group that can merge into this branch. In GitLab Premium, you can also add users.
|
||||
1. From the **Allowed to push** list, select a role, group, or user that can push to this branch. In GitLab Premium, you can also add users.
|
||||
1. Select **Protect**.
|
||||
|
||||
The protected branch displays in the **Protected branches** list.
|
||||
The protected branch displays in the list of protected branches.
|
||||
|
||||
## Using the Allowed to merge and Allowed to push settings
|
||||
## Configure multiple protected branches by using a wildcard
|
||||
|
||||
In GitLab 8.11 and later, we added another layer of branch protection which provides
|
||||
more granular management of protected branches. The **Developers can push**
|
||||
option was replaced by **Allowed to push**. You can set this value to allow
|
||||
or prohibit Maintainers and/or Developers to push to a protected branch.
|
||||
Prerequisite:
|
||||
|
||||
Using the **Allowed to push** and **Allowed to merge** settings, you can control
|
||||
the actions that different roles can perform with the protected branch.
|
||||
For example, you could set **Allowed to push** to "No one", and **Allowed to merge**
|
||||
to "Developers + Maintainers", to require everyone to submit a merge request for
|
||||
changes going into the protected branch. This is compatible with workflows like
|
||||
the [GitLab workflow](../../topics/gitlab_flow.md).
|
||||
- You must have at least the [Maintainer role](../permissions.md).
|
||||
|
||||
However, there are workflows where that is not needed, and only protecting from
|
||||
force pushes and branch removal is useful. For those workflows, you can allow
|
||||
everyone with write access to push to a protected branch by setting
|
||||
**Allowed to push** to "Developers + Maintainers".
|
||||
To protect multiple branches at the same time:
|
||||
|
||||
You can set the **Allowed to push** and **Allowed to merge** options while creating
|
||||
a protected branch or afterwards by selecting the option you want from the
|
||||
dropdown list in the **Already protected** area.
|
||||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. From the **Branch** dropdown menu, type the branch name and a wildcard.
|
||||
For example:
|
||||
|
||||
|
||||
| Wildcard protected branch | Matching branches |
|
||||
|---------------------------|--------------------------------------------------------|
|
||||
| `*-stable` | `production-stable`, `staging-stable` |
|
||||
| `production/*` | `production/app-server`, `production/load-balancer` |
|
||||
| `*gitlab*` | `gitlab`, `gitlab/staging`, `master/gitlab/production` |
|
||||
|
||||
If you don't choose any of those options while creating a protected branch,
|
||||
they are set to Maintainers by default.
|
||||
1. From the **Allowed to merge** list, select a role, or group that can merge into this branch. In GitLab Premium, you can also add users.
|
||||
1. From the **Allowed to push** list, select a role, group, or user that can push to this branch. In GitLab Premium, you can also add users.
|
||||
1. Select **Protect**.
|
||||
|
||||
### Allow deploy keys to push to a protected branch
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30769) in GitLab 13.7.
|
||||
> - This feature is being selectively deployed in GitLab.com 13.7, and may not be available for all users.
|
||||
> - This feature is available for all users in GitLab 13.9.
|
||||
|
||||
You can allow specific machines to access protected branches in your repository with
|
||||
[deploy keys](deploy_keys/index.md). This can be useful for your CI/CD workflow,
|
||||
for example.
|
||||
|
||||
Deploy keys can be selected in the **Allowed to push** dropdown when:
|
||||
|
||||
- Defining a protected branch.
|
||||
- Updating an existing branch.
|
||||
|
||||
Select a deploy key to allow the key's owner to push to the chosen protected branch,
|
||||
even if they aren't a member of the related project. The owner of the selected deploy
|
||||
key must have at least read access to the given project.
|
||||
|
||||
For a deploy key to be selectable:
|
||||
|
||||
- It must be [enabled for your project](deploy_keys/index.md#how-to-enable-deploy-keys).
|
||||
- It must have [write access](deploy_keys/index.md#deploy-keys-permissions) to your project repository.
|
||||
|
||||
Deploy keys are not available in the **Allowed to merge** dropdown.
|
||||
|
||||
|
||||
|
||||
## Restricting push and merge access to certain users **(PREMIUM)**
|
||||
|
||||
With GitLab Premium you can restrict access to protected branches
|
||||
by choosing a role (Maintainers, Developers) and certain users. From the
|
||||
dropdown menu select the role and/or the users you want to have merge or push
|
||||
access.
|
||||
|
||||
|
||||
|
||||
Click **Protect** and the branch displays in the **Protected branch** list.
|
||||
|
||||
|
||||
|
||||
## Wildcard protected branches
|
||||
|
||||
You can specify a wildcard protected branch, which protects all branches
|
||||
matching the wildcard. For example:
|
||||
|
||||
| Wildcard Protected Branch | Matching Branches |
|
||||
|---------------------------|--------------------------------------------------------|
|
||||
| `*-stable` | `production-stable`, `staging-stable` |
|
||||
| `production/*` | `production/app-server`, `production/load-balancer` |
|
||||
| `*gitlab*` | `gitlab`, `gitlab/staging`, `master/gitlab/production` |
|
||||
|
||||
Protected branch settings, like **Developers can push**, apply to all matching
|
||||
branches.
|
||||
|
||||
Two different wildcards can potentially match the same branch. For example,
|
||||
`*-stable` and `production-*` would both match a `production-stable` branch.
|
||||
In that case, if _any_ of these protected branches have a setting like
|
||||
"Allowed to push", then `production-stable` also inherit this setting.
|
||||
|
||||
If you click on a protected branch's name, GitLab displays a list of
|
||||
all matching branches:
|
||||
|
||||
|
||||
The protected branch displays in the list of protected branches.
|
||||
|
||||
## Create a protected branch
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53361) in GitLab 11.9.
|
||||
|
||||
When a protected branch or wildcard protected branches are set to
|
||||
[**No one** is **Allowed to push**](#using-the-allowed-to-merge-and-allowed-to-push-settings),
|
||||
Developers (and users with higher [permission levels](../permissions.md)) are
|
||||
allowed to create a new protected branch as long as they are
|
||||
[**Allowed to merge**](#using-the-allowed-to-merge-and-allowed-to-push-settings).
|
||||
This can only be done by using the UI or through the API, to avoid creating protected
|
||||
branches accidentally from the command line or from a Git client application.
|
||||
Users with the Developer or higher [role](../permissions.md) can create a protected branch.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- **Allowed to push** is set to **No one**
|
||||
- **Allowed to merge** is set to **Developers**.
|
||||
|
||||
You can create a protected branch by using the UI or API only.
|
||||
This prevents you from accidentally creating a branch
|
||||
from the command line or from a Git client application.
|
||||
|
||||
To create a new branch through the user interface:
|
||||
|
||||
1. Go to **Repository > Branches**.
|
||||
1. Click on **New branch**.
|
||||
1. Select **New branch**.
|
||||
1. Fill in the branch name and select an existing branch, tag, or commit to
|
||||
base the new branch on. Only existing protected branches and commits
|
||||
that are already in protected branches are accepted.
|
||||
|
||||
## Delete a protected branch
|
||||
## Require everyone to submit merge requests for a protected branch
|
||||
|
||||
From time to time, you may need to delete or clean up protected branches.
|
||||
User with the [Maintainer role](../permissions.md) and greater can manually delete protected
|
||||
branches by using the GitLab web interface:
|
||||
You can force everyone to submit a merge request, rather than allowing them to check in directly
|
||||
to a protected branch. This is compatible with workflows like the [GitLab workflow](../../topics/gitlab_flow.md).
|
||||
|
||||
1. Go to **Repository > Branches**.
|
||||
1. Click on the delete icon next to the branch you wish to delete.
|
||||
1. To prevent accidental deletion, an additional confirmation is required.
|
||||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. From the **Branch** dropdown menu, select the branch you want to protect.
|
||||
1. From the **Allowed to merge** list, select **Developers + Maintainers**.
|
||||
1. From the **Allowed to push** list, select **No one**.
|
||||
1. Select **Protect**.
|
||||
|
||||
|
||||
## Allow everyone to push directly to a protected branch
|
||||
|
||||
Deleting a protected branch is allowed only by using the web interface; not from Git.
|
||||
This means that you can't accidentally delete a protected branch from your
|
||||
command line or a Git client application.
|
||||
You can allow everyone with write access to push to the protected branch.
|
||||
|
||||
## Allow force push on protected branches
|
||||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. From the **Branch** dropdown menu, select the branch you want to protect.
|
||||
1. From the **Allowed to push** list, select **Developers + Maintainers**.
|
||||
1. Select **Protect**.
|
||||
|
||||
## Allow deploy keys to push to a protected branch
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/30769) in GitLab 13.7.
|
||||
> - This feature was selectively deployed in GitLab.com 13.7, and may not be available for all users.
|
||||
> - This feature is available for all users in GitLab 13.9.
|
||||
|
||||
You can permit the owner of a [deploy key](deploy_keys/index.md) to push to a protected branch.
|
||||
The deploy key works, even if the user isn't a member of the related project. However, the owner of the deploy
|
||||
key must have at least read access to the project.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The deploy key must be [enabled for your project](deploy_keys/index.md#how-to-enable-deploy-keys).
|
||||
- The deploy key must have [write access](deploy_keys/index.md#deploy-keys-permissions) to your project repository.
|
||||
|
||||
To allow a deploy key to push to a protected branch:
|
||||
|
||||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. From the **Branch** dropdown menu, select the branch you want to protect.
|
||||
1. From the **Allowed to push** list, select the deploy key.
|
||||
1. Select **Protect**.
|
||||
|
||||
Deploy keys are not available in the **Allowed to merge** dropdown.
|
||||
|
||||
## Allow force push on a protected branch
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/15611) in GitLab 13.10 behind a disabled feature flag.
|
||||
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/323431) in GitLab 14.0.
|
||||
|
|
@ -185,68 +153,77 @@ WARNING:
|
|||
This feature might not be available to you. Check the **version history** note above for details.
|
||||
|
||||
You can allow [force pushes](../../topics/git/git_rebase.md#force-push) to
|
||||
protected branches by either setting **Allowed to force push**
|
||||
when you protect a new branch, or by configuring an already-protected branch.
|
||||
protected branches.
|
||||
|
||||
To protect a new branch and enable Force push:
|
||||
To protect a new branch and enable force push:
|
||||
|
||||
1. Navigate to your project's **Settings > Repository**.
|
||||
1. Expand **Protected branches**, and scroll to **Protect a branch**.
|
||||
1. Select a **Branch** or wildcard you'd like to protect.
|
||||
1. Select the user levels **Allowed to merge** and **Allowed to push**.
|
||||
1. To allow all users with push access to force push, toggle the **Allowed to force push** slider.
|
||||
1. To reject code pushes that change files listed in the `CODEOWNERS` file, toggle
|
||||
**Require approval from code owners**.
|
||||
1. Click **Protect**.
|
||||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. From the **Branch** dropdown menu, select the branch you want to protect.
|
||||
1. From the **Allowed to push** and **Allowed to merge** lists, select the settings you want.
|
||||
1. To allow all users with push access to force push, turn on the **Allowed to force push** toggle.
|
||||
1. To reject code pushes that change files listed in the `CODEOWNERS` file, turn on the
|
||||
**Require approval from code owners** toggle.
|
||||
1. Select **Protect**.
|
||||
|
||||
To enable force pushes on branches already protected:
|
||||
To enable force pushes on branches that are already protected:
|
||||
|
||||
1. Navigate to your project's **Settings > Repository**.
|
||||
1. Expand **Protected branches** and scroll to **Protected branch**.
|
||||
1. Toggle the **Allowed to force push** slider for the chosen branch.
|
||||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. In the list of protected branches, next to the branch, turn on the **Allowed to force push** toggle.
|
||||
|
||||
When enabled, members who are allowed to push to this branch can also force push.
|
||||
When enabled, members who are can push to this branch can also force push.
|
||||
|
||||
## Protected branches approval by Code Owners **(PREMIUM)**
|
||||
## Require Code Owner approval on a protected branch **(PREMIUM)**
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/13251) in GitLab Premium 12.4.
|
||||
|
||||
It is possible to require at least one approval by a
|
||||
You can require at least one approval by a
|
||||
[Code Owner](code_owners.md) to a file changed by the
|
||||
merge request. You can either set Code Owners approvals
|
||||
at the time you protect a new branch, or set it to a branch
|
||||
already protected, as described below.
|
||||
merge request.
|
||||
|
||||
To protect a new branch and enable Code Owner's approval:
|
||||
|
||||
1. Navigate to your project's **Settings > Repository** and expand **Protected branches**.
|
||||
1. Scroll down to **Protect a branch**, select a **Branch** or wildcard you'd like to protect, select who's **Allowed to merge** and **Allowed to push**, and toggle the **Require approval from code owners** slider.
|
||||
1. Click **Protect**.
|
||||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. From the **Branch** dropdown menu, select the branch you want to protect.
|
||||
1. From the **Allowed to push** and **Allowed to merge** lists, select the settings you want.
|
||||
1. Turn on the **Require approval from code owners** toggle.
|
||||
1. Select **Protect**.
|
||||
|
||||
To enable Code Owner's approval to branches already protected:
|
||||
To enable Code Owner's approval on branches that are already protected:
|
||||
|
||||
1. Navigate to your project's **Settings > Repository** and expand **Protected branches**.
|
||||
1. Scroll down to **Protected branch** and toggle the **Code owner approval** slider for the chosen branch.
|
||||
1. Go to your project and select **Settings > Repository**.
|
||||
1. Expand **Protected branches**.
|
||||
1. In the list of protected branches, next to the branch, turn on the **Code owner approval** toggle.
|
||||
|
||||
When enabled, all merge requests targeting these branches require approval
|
||||
When enabled, all merge requests for these branches require approval
|
||||
by a Code Owner per matched rule before they can be merged.
|
||||
Additionally, direct pushes to the protected branch are denied if a rule is matched.
|
||||
|
||||
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/35097) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.5, users and groups who are allowed to push to protected branches do not require a merge request to merge their feature branches. Thus, they can skip merge request approval rules.
|
||||
[In](https://gitlab.com/gitlab-org/gitlab/-/issues/35097) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.5 and later,
|
||||
users and groups who can push to protected branches do not have to use a merge request to merge their feature branches. Thus, they can skip merge request approval rules.
|
||||
|
||||
## Running pipelines on protected branches
|
||||
## Run pipelines on protected branches
|
||||
|
||||
The permission to merge or push to protected branches is used to define if a user can
|
||||
run CI/CD pipelines and execute actions on jobs that are related to those branches.
|
||||
The permission to merge or push to protected branches defines
|
||||
whether or not a user can run CI/CD pipelines and execute actions on jobs.
|
||||
|
||||
See [Security on protected branches](../../ci/pipelines/index.md#pipeline-security-on-protected-branches)
|
||||
for details about the pipelines security model.
|
||||
|
||||
## Changelog
|
||||
## Delete a protected branch
|
||||
|
||||
- **13.5**: [Allow Deploy keys to push to protected branches once more](https://gitlab.com/gitlab-org/gitlab/-/issues/30769).
|
||||
- **11.9**: [Allow protected branches to be created](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/53361)
|
||||
by Developers (and users with higher permission levels) through the API and the user interface.
|
||||
Users with the [Maintainer role](../permissions.md) and greater can manually delete protected
|
||||
branches by using the GitLab web interface:
|
||||
|
||||
1. Go to **Repository > Branches**.
|
||||
1. Next to the branch you want to delete, select the **Delete** button (**{remove}**).
|
||||
1. On the confirmation dialog, type the branch name and select **Delete protected branch**.
|
||||
|
||||
You can delete a protected branch from the UI only.
|
||||
This prevents you from accidentally deleting a branch
|
||||
from the command line or from a Git client application.
|
||||
|
||||
<!-- ## Troubleshooting
|
||||
|
||||
|
|
|
|||
|
|
@ -52,7 +52,12 @@ module Gitlab
|
|||
end
|
||||
|
||||
if (template = hash['template'])
|
||||
config.template = Parser.new.parse_and_transform(template)
|
||||
config.template =
|
||||
begin
|
||||
TemplateParser::Parser.new.parse_and_transform(template)
|
||||
rescue TemplateParser::Error => e
|
||||
raise Error, e.message
|
||||
end
|
||||
end
|
||||
|
||||
if (categories = hash['categories'])
|
||||
|
|
@ -73,7 +78,12 @@ module Gitlab
|
|||
def initialize(project)
|
||||
@project = project
|
||||
@date_format = DEFAULT_DATE_FORMAT
|
||||
@template = Parser.new.parse_and_transform(DEFAULT_TEMPLATE)
|
||||
@template =
|
||||
begin
|
||||
TemplateParser::Parser.new.parse_and_transform(DEFAULT_TEMPLATE)
|
||||
rescue TemplateParser::Error => e
|
||||
raise Error, e.message
|
||||
end
|
||||
@categories = {}
|
||||
@tag_regex = DEFAULT_TAG_REGEX
|
||||
end
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ module Gitlab
|
|||
end
|
||||
|
||||
def to_markdown
|
||||
state = EvalState.new
|
||||
state = TemplateParser::EvalState.new
|
||||
data = { 'categories' => entries_for_template }
|
||||
|
||||
# While not critical, we would like release sections to be separated by
|
||||
|
|
@ -63,7 +63,12 @@ module Gitlab
|
|||
#
|
||||
# Since it can be a bit tricky to get this right in a template, we
|
||||
# enforce an empty line separator ourselves.
|
||||
markdown = @config.template.evaluate(state, data).strip
|
||||
markdown =
|
||||
begin
|
||||
@config.template.evaluate(state, data).strip
|
||||
rescue TemplateParser::ParseError => e
|
||||
raise Error, e.message
|
||||
end
|
||||
|
||||
# The release header can't be changed using the Liquid template, as we
|
||||
# need this to be in a known format. Without this restriction, we won't
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ module Gitlab
|
|||
#
|
||||
class RunnerMatcher
|
||||
ATTRIBUTES = %i[
|
||||
runner_ids
|
||||
runner_type
|
||||
public_projects_minutes_cost_factor
|
||||
private_projects_minutes_cost_factor
|
||||
|
|
|
|||
|
|
@ -62,9 +62,6 @@ module Gitlab
|
|||
learn_gitlab_b: {
|
||||
tracking_category: 'Growth::Activation::Experiment::LearnGitLabB',
|
||||
rollout_strategy: :user
|
||||
},
|
||||
in_product_marketing_emails: {
|
||||
tracking_category: 'Growth::Activation::Experiment::InProductMarketingEmails'
|
||||
}
|
||||
}.freeze
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Gitlab
|
||||
module Changelog
|
||||
module TemplateParser
|
||||
# AST nodes to evaluate when rendering a template.
|
||||
#
|
||||
# Evaluating an AST is done by walking over the nodes and calling
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Gitlab
|
||||
module TemplateParser
|
||||
# An error raised when a template couldn't be rendered.
|
||||
Error = Class.new(StandardError)
|
||||
end
|
||||
end
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Gitlab
|
||||
module Changelog
|
||||
module TemplateParser
|
||||
# A class for tracking state when evaluating a template
|
||||
class EvalState
|
||||
MAX_LOOPS = 4
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
module Gitlab
|
||||
module Changelog
|
||||
# A parser for the template syntax used for generating changelogs.
|
||||
module TemplateParser
|
||||
# A parser for a simple template syntax, used for example to generate changelogs.
|
||||
#
|
||||
# As a quick primer on the template syntax, a basic template looks like
|
||||
# this:
|
||||
|
|
@ -166,7 +166,7 @@ module Gitlab
|
|||
def parse_and_transform(input)
|
||||
AST::Transformer.new.apply(parse(input))
|
||||
rescue Parslet::ParseFailed => ex
|
||||
# We raise a custom error so it's easier to catch different changelog
|
||||
# We raise a custom error so it's easier to catch different parser
|
||||
# related errors. In addition, this ensures the caller of this method
|
||||
# doesn't depend on a Parslet specific error class.
|
||||
raise Error, "Failed to parse the template: #{ex.message}"
|
||||
|
|
@ -13326,9 +13326,6 @@ msgstr ""
|
|||
msgid "Expires"
|
||||
msgstr ""
|
||||
|
||||
msgid "Expires at"
|
||||
msgstr ""
|
||||
|
||||
msgid "Expires at (optional)"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -14266,6 +14263,9 @@ msgstr ""
|
|||
msgid "For each job, re-use the project workspace. If the workspace doesn't exist, use %{code_open}git clone%{code_close}."
|
||||
msgstr ""
|
||||
|
||||
msgid "For example, the application using the token or the purpose of the token."
|
||||
msgstr ""
|
||||
|
||||
msgid "For general work"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -17689,7 +17689,13 @@ msgstr ""
|
|||
msgid "Integrations|Failed to unlink namespace. Please try again."
|
||||
msgstr ""
|
||||
|
||||
msgid "Integrations|GitLab administrators can set up integrations that all projects inherit and use by default. These integrations apply to all projects that don't already use custom settings. You can override custom settings for a group or project if the settings are necessary at that level. Learn more about %{integrations_link_start}project integration management%{link_end}."
|
||||
msgid "Integrations|GitLab administrators can set up integrations that all groups and projects inherit and use by default. These integrations apply to all groups and projects that don't already use custom settings. You can override custom settings for a group or project if the settings are necessary at that level. Learn more about %{integrations_link_start}instance-level integration management%{link_end}."
|
||||
msgstr ""
|
||||
|
||||
msgid "Integrations|GitLab administrators can set up integrations that all projects in a group inherit and use by default. These integrations apply to all projects that don't already use custom settings. You can override custom settings for a project if the settings are necessary at that level. Learn more about %{integrations_link_start}group-level integration management%{link_end}."
|
||||
msgstr ""
|
||||
|
||||
msgid "Integrations|Group-level integration management"
|
||||
msgstr ""
|
||||
|
||||
msgid "Integrations|Includes Standard, plus the entire commit message, commit hash, and issue IDs"
|
||||
|
|
@ -17698,6 +17704,9 @@ msgstr ""
|
|||
msgid "Integrations|Includes commit title and branch."
|
||||
msgstr ""
|
||||
|
||||
msgid "Integrations|Instance-level integration management"
|
||||
msgstr ""
|
||||
|
||||
msgid "Integrations|Issues created in Jira are shown here once you have created the issues in project setup in Jira."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -17722,9 +17731,6 @@ msgstr ""
|
|||
msgid "Integrations|Note: this integration only works with accounts on GitLab.com (SaaS)."
|
||||
msgstr ""
|
||||
|
||||
msgid "Integrations|Project integration management"
|
||||
msgstr ""
|
||||
|
||||
msgid "Integrations|Projects using custom settings will not be affected."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -34297,9 +34303,18 @@ msgstr ""
|
|||
msgid "Token"
|
||||
msgstr ""
|
||||
|
||||
msgid "Token name"
|
||||
msgstr ""
|
||||
|
||||
msgid "Token valid until revoked"
|
||||
msgstr ""
|
||||
|
||||
msgid "Tokens|Scopes set the permission levels granted to the token."
|
||||
msgstr ""
|
||||
|
||||
msgid "Tokens|Select scopes"
|
||||
msgstr ""
|
||||
|
||||
msgid "Tomorrow"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -28,10 +28,10 @@ RSpec.describe 'Admin > Users > Impersonation Tokens', :js do
|
|||
name = 'Hello World'
|
||||
|
||||
visit admin_user_impersonation_tokens_path(user_id: user.username)
|
||||
fill_in "Name", with: name
|
||||
fill_in "Token name", with: name
|
||||
|
||||
# Set date to 1st of next month
|
||||
find_field("Expires at").click
|
||||
find_field("Expiration date").click
|
||||
find(".pika-next").click
|
||||
click_on "1"
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ RSpec.describe 'User searches group settings', :js do
|
|||
visit group_settings_integrations_path(group)
|
||||
end
|
||||
|
||||
it_behaves_like 'can highlight results', 'Project integration management'
|
||||
it_behaves_like 'can highlight results', 'Group-level integration management'
|
||||
end
|
||||
|
||||
context 'in Repository page' do
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ RSpec.describe 'Merge request > User toggles whitespace changes', :js do
|
|||
end
|
||||
|
||||
describe 'clicking "Hide whitespace changes" button' do
|
||||
it 'toggles the "Hide whitespace changes" button' do
|
||||
it 'toggles the "Hide whitespace changes" button', quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/333793' do
|
||||
find('[data-testid="show-whitespace"]').click
|
||||
|
||||
visit diffs_project_merge_request_path(project, merge_request)
|
||||
|
|
|
|||
|
|
@ -42,10 +42,10 @@ RSpec.describe 'Profile > Personal Access Tokens', :js do
|
|||
name = 'My PAT'
|
||||
|
||||
visit profile_personal_access_tokens_path
|
||||
fill_in "Name", with: name
|
||||
fill_in "Token name", with: name
|
||||
|
||||
# Set date to 1st of next month
|
||||
find_field("Expires at").click
|
||||
find_field("Expiration date").click
|
||||
find(".pika-next").click
|
||||
click_on "1"
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ RSpec.describe 'Profile > Personal Access Tokens', :js do
|
|||
it "displays an error message" do
|
||||
disallow_personal_access_token_saves!
|
||||
visit profile_personal_access_tokens_path
|
||||
fill_in "Name", with: 'My PAT'
|
||||
fill_in "Token name", with: 'My PAT'
|
||||
|
||||
expect { click_on "Create personal access token" }.not_to change { PersonalAccessToken.count }
|
||||
expect(page).to have_content("Name cannot be nil")
|
||||
|
|
|
|||
|
|
@ -51,10 +51,10 @@ RSpec.describe 'Project > Settings > Access Tokens', :js do
|
|||
name = 'My project access token'
|
||||
|
||||
visit project_settings_access_tokens_path(project)
|
||||
fill_in 'Name', with: name
|
||||
fill_in 'Token name', with: name
|
||||
|
||||
# Set date to 1st of next month
|
||||
find_field('Expires at').click
|
||||
find_field('Expiration date').click
|
||||
find('.pika-next').click
|
||||
click_on '1'
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ RSpec.describe 'User searches project settings', :js do
|
|||
visit project_settings_access_tokens_path(project)
|
||||
end
|
||||
|
||||
it_behaves_like 'can highlight results', 'Expires at'
|
||||
it_behaves_like 'can highlight results', 'Expiration date'
|
||||
end
|
||||
|
||||
context 'in Repository page' do
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ RSpec.describe Gitlab::Changelog::Config do
|
|||
|
||||
expect(config.date_format).to eq('foo')
|
||||
expect(config.template)
|
||||
.to be_instance_of(Gitlab::Changelog::AST::Expressions)
|
||||
.to be_instance_of(Gitlab::TemplateParser::AST::Expressions)
|
||||
|
||||
expect(config.categories).to eq({ 'foo' => 'bar' })
|
||||
expect(config.tag_regex).to eq('foo')
|
||||
|
|
@ -53,6 +53,16 @@ RSpec.describe Gitlab::Changelog::Config do
|
|||
expect { described_class.from_hash(project, 'categories' => 10) }
|
||||
.to raise_error(Gitlab::Changelog::Error)
|
||||
end
|
||||
|
||||
it 'raises a Gitlab::Changelog::Error when the template is invalid' do
|
||||
invalid_template = <<~TPL
|
||||
{% each {{foo}} %}
|
||||
{% end %}
|
||||
TPL
|
||||
|
||||
expect { described_class.from_hash(project, 'template' => invalid_template) }
|
||||
.to raise_error(Gitlab::Changelog::Error)
|
||||
end
|
||||
end
|
||||
|
||||
describe '#contributor?' do
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ require 'spec_helper'
|
|||
RSpec.describe Gitlab::Ci::Matching::RunnerMatcher do
|
||||
let(:dummy_attributes) do
|
||||
{
|
||||
runner_ids: [1],
|
||||
runner_type: 'instance_type',
|
||||
public_projects_minutes_cost_factor: 0,
|
||||
private_projects_minutes_cost_factor: 1,
|
||||
|
|
@ -26,6 +27,8 @@ RSpec.describe Gitlab::Ci::Matching::RunnerMatcher do
|
|||
context 'with attributes' do
|
||||
let(:attributes) { dummy_attributes }
|
||||
|
||||
it { expect(matcher.runner_ids).to eq([1]) }
|
||||
|
||||
it { expect(matcher.runner_type).to eq('instance_type') }
|
||||
|
||||
it { expect(matcher.public_projects_minutes_cost_factor).to eq(0) }
|
||||
|
|
|
|||
|
|
@ -2,8 +2,8 @@
|
|||
|
||||
require 'spec_helper'
|
||||
|
||||
RSpec.describe Gitlab::Changelog::AST::Identifier do
|
||||
let(:state) { Gitlab::Changelog::EvalState.new }
|
||||
RSpec.describe Gitlab::TemplateParser::AST::Identifier do
|
||||
let(:state) { Gitlab::TemplateParser::EvalState.new }
|
||||
|
||||
describe '#evaluate' do
|
||||
it 'evaluates a selector' do
|
||||
|
|
@ -26,8 +26,8 @@ RSpec.describe Gitlab::Changelog::AST::Identifier do
|
|||
end
|
||||
end
|
||||
|
||||
RSpec.describe Gitlab::Changelog::AST::Integer do
|
||||
let(:state) { Gitlab::Changelog::EvalState.new }
|
||||
RSpec.describe Gitlab::TemplateParser::AST::Integer do
|
||||
let(:state) { Gitlab::TemplateParser::EvalState.new }
|
||||
|
||||
describe '#evaluate' do
|
||||
it 'evaluates a selector' do
|
||||
|
|
@ -44,33 +44,33 @@ RSpec.describe Gitlab::Changelog::AST::Integer do
|
|||
end
|
||||
end
|
||||
|
||||
RSpec.describe Gitlab::Changelog::AST::Selector do
|
||||
let(:state) { Gitlab::Changelog::EvalState.new }
|
||||
RSpec.describe Gitlab::TemplateParser::AST::Selector do
|
||||
let(:state) { Gitlab::TemplateParser::EvalState.new }
|
||||
let(:data) { { 'numbers' => [10] } }
|
||||
|
||||
describe '#evaluate' do
|
||||
it 'evaluates a selector' do
|
||||
ident = Gitlab::Changelog::AST::Identifier.new('numbers')
|
||||
int = Gitlab::Changelog::AST::Integer.new(0)
|
||||
ident = Gitlab::TemplateParser::AST::Identifier.new('numbers')
|
||||
int = Gitlab::TemplateParser::AST::Integer.new(0)
|
||||
|
||||
expect(described_class.new([ident, int]).evaluate(state, data)).to eq(10)
|
||||
end
|
||||
|
||||
it 'evaluates a selector that returns nil' do
|
||||
int = Gitlab::Changelog::AST::Integer.new(0)
|
||||
int = Gitlab::TemplateParser::AST::Integer.new(0)
|
||||
|
||||
expect(described_class.new([int]).evaluate(state, data)).to be_nil
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
RSpec.describe Gitlab::Changelog::AST::Variable do
|
||||
let(:state) { Gitlab::Changelog::EvalState.new }
|
||||
RSpec.describe Gitlab::TemplateParser::AST::Variable do
|
||||
let(:state) { Gitlab::TemplateParser::EvalState.new }
|
||||
let(:data) { { 'numbers' => [10] } }
|
||||
|
||||
describe '#evaluate' do
|
||||
it 'evaluates a variable' do
|
||||
node = Gitlab::Changelog::Parser
|
||||
node = Gitlab::TemplateParser::Parser
|
||||
.new
|
||||
.parse_and_transform('{{numbers.0}}')
|
||||
.nodes[0]
|
||||
|
|
@ -80,26 +80,26 @@ RSpec.describe Gitlab::Changelog::AST::Variable do
|
|||
|
||||
it 'evaluates an undefined variable' do
|
||||
node =
|
||||
Gitlab::Changelog::Parser.new.parse_and_transform('{{foobar}}').nodes[0]
|
||||
Gitlab::TemplateParser::Parser.new.parse_and_transform('{{foobar}}').nodes[0]
|
||||
|
||||
expect(node.evaluate(state, data)).to eq('')
|
||||
end
|
||||
|
||||
it 'evaluates the special variable "it"' do
|
||||
node =
|
||||
Gitlab::Changelog::Parser.new.parse_and_transform('{{it}}').nodes[0]
|
||||
Gitlab::TemplateParser::Parser.new.parse_and_transform('{{it}}').nodes[0]
|
||||
|
||||
expect(node.evaluate(state, data)).to eq(data.to_s)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
RSpec.describe Gitlab::Changelog::AST::Expressions do
|
||||
let(:state) { Gitlab::Changelog::EvalState.new }
|
||||
RSpec.describe Gitlab::TemplateParser::AST::Expressions do
|
||||
let(:state) { Gitlab::TemplateParser::EvalState.new }
|
||||
|
||||
describe '#evaluate' do
|
||||
it 'evaluates all expressions' do
|
||||
node = Gitlab::Changelog::Parser
|
||||
node = Gitlab::TemplateParser::Parser
|
||||
.new
|
||||
.parse_and_transform('{{number}}foo')
|
||||
|
||||
|
|
@ -108,8 +108,8 @@ RSpec.describe Gitlab::Changelog::AST::Expressions do
|
|||
end
|
||||
end
|
||||
|
||||
RSpec.describe Gitlab::Changelog::AST::Text do
|
||||
let(:state) { Gitlab::Changelog::EvalState.new }
|
||||
RSpec.describe Gitlab::TemplateParser::AST::Text do
|
||||
let(:state) { Gitlab::TemplateParser::EvalState.new }
|
||||
|
||||
describe '#evaluate' do
|
||||
it 'returns the text' do
|
||||
|
|
@ -118,12 +118,12 @@ RSpec.describe Gitlab::Changelog::AST::Text do
|
|||
end
|
||||
end
|
||||
|
||||
RSpec.describe Gitlab::Changelog::AST::If do
|
||||
let(:state) { Gitlab::Changelog::EvalState.new }
|
||||
RSpec.describe Gitlab::TemplateParser::AST::If do
|
||||
let(:state) { Gitlab::TemplateParser::EvalState.new }
|
||||
|
||||
describe '#evaluate' do
|
||||
it 'evaluates a truthy if expression without an else clause' do
|
||||
node = Gitlab::Changelog::Parser
|
||||
node = Gitlab::TemplateParser::Parser
|
||||
.new
|
||||
.parse_and_transform('{% if thing %}foo{% end %}')
|
||||
.nodes[0]
|
||||
|
|
@ -132,7 +132,7 @@ RSpec.describe Gitlab::Changelog::AST::If do
|
|||
end
|
||||
|
||||
it 'evaluates a falsy if expression without an else clause' do
|
||||
node = Gitlab::Changelog::Parser
|
||||
node = Gitlab::TemplateParser::Parser
|
||||
.new
|
||||
.parse_and_transform('{% if thing %}foo{% end %}')
|
||||
.nodes[0]
|
||||
|
|
@ -141,7 +141,7 @@ RSpec.describe Gitlab::Changelog::AST::If do
|
|||
end
|
||||
|
||||
it 'evaluates a falsy if expression with an else clause' do
|
||||
node = Gitlab::Changelog::Parser
|
||||
node = Gitlab::TemplateParser::Parser
|
||||
.new
|
||||
.parse_and_transform('{% if thing %}foo{% else %}bar{% end %}')
|
||||
.nodes[0]
|
||||
|
|
@ -177,13 +177,13 @@ RSpec.describe Gitlab::Changelog::AST::If do
|
|||
end
|
||||
end
|
||||
|
||||
RSpec.describe Gitlab::Changelog::AST::Each do
|
||||
let(:state) { Gitlab::Changelog::EvalState.new }
|
||||
RSpec.describe Gitlab::TemplateParser::AST::Each do
|
||||
let(:state) { Gitlab::TemplateParser::EvalState.new }
|
||||
|
||||
describe '#evaluate' do
|
||||
it 'evaluates the expression' do
|
||||
data = { 'animals' => [{ 'name' => 'Cat' }, { 'name' => 'Dog' }] }
|
||||
node = Gitlab::Changelog::Parser
|
||||
node = Gitlab::TemplateParser::Parser
|
||||
.new
|
||||
.parse_and_transform('{% each animals %}{{name}}{% end %}')
|
||||
.nodes[0]
|
||||
|
|
@ -193,7 +193,7 @@ RSpec.describe Gitlab::Changelog::AST::Each do
|
|||
|
||||
it 'returns an empty string when the input is not a collection' do
|
||||
data = { 'animals' => 10 }
|
||||
node = Gitlab::Changelog::Parser
|
||||
node = Gitlab::TemplateParser::Parser
|
||||
.new
|
||||
.parse_and_transform('{% each animals %}{{name}}{% end %}')
|
||||
.nodes[0]
|
||||
|
|
@ -237,10 +237,10 @@ RSpec.describe Gitlab::Changelog::AST::Each do
|
|||
TPL
|
||||
|
||||
node =
|
||||
Gitlab::Changelog::Parser.new.parse_and_transform(template).nodes[0]
|
||||
Gitlab::TemplateParser::Parser.new.parse_and_transform(template).nodes[0]
|
||||
|
||||
expect { node.evaluate(state, data) }
|
||||
.to raise_error(Gitlab::Changelog::Error)
|
||||
.to raise_error(Gitlab::TemplateParser::Error)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
require 'spec_helper'
|
||||
|
||||
RSpec.describe Gitlab::Changelog::Parser do
|
||||
RSpec.describe Gitlab::TemplateParser::Parser do
|
||||
let(:parser) { described_class.new }
|
||||
|
||||
describe '#root' do
|
||||
|
|
@ -67,12 +67,12 @@ RSpec.describe Gitlab::Changelog::Parser do
|
|||
it 'parses and transforms a template' do
|
||||
node = parser.parse_and_transform('foo')
|
||||
|
||||
expect(node).to be_instance_of(Gitlab::Changelog::AST::Expressions)
|
||||
expect(node).to be_instance_of(Gitlab::TemplateParser::AST::Expressions)
|
||||
end
|
||||
|
||||
it 'raises parsing errors using a custom error class' do
|
||||
expect { parser.parse_and_transform('{% each') }
|
||||
.to raise_error(Gitlab::Changelog::Error)
|
||||
.to raise_error(Gitlab::TemplateParser::Error)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -1086,6 +1086,18 @@ RSpec.describe Ci::Runner do
|
|||
expect(matchers.map(&:tag_list)).to match_array([%w[tag1 tag2], %w[tag3 tag4]])
|
||||
end
|
||||
end
|
||||
|
||||
context 'with runner_ids' do
|
||||
before do
|
||||
create_list(:ci_runner, 2)
|
||||
end
|
||||
|
||||
it 'includes runner_ids' do
|
||||
expect(matchers.size).to eq(1)
|
||||
|
||||
expect(matchers.first.runner_ids).to match_array(described_class.all.pluck(:id))
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#runner_matcher' do
|
||||
|
|
@ -1095,6 +1107,8 @@ RSpec.describe Ci::Runner do
|
|||
|
||||
subject(:matcher) { runner.runner_matcher }
|
||||
|
||||
it { expect(matcher.runner_ids).to eq([runner.id]) }
|
||||
|
||||
it { expect(matcher.runner_type).to eq(runner.runner_type) }
|
||||
|
||||
it { expect(matcher.public_projects_minutes_cost_factor).to eq(runner.public_projects_minutes_cost_factor) }
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ RSpec.describe Namespaces::InProductMarketingEmailsService, '#execute' do
|
|||
let(:frozen_time) { Time.zone.parse('23 Mar 2021 10:14:40 UTC') }
|
||||
let(:previous_action_completed_at) { frozen_time - 2.days }
|
||||
let(:current_action_completed_at) { nil }
|
||||
let(:experiment_enabled) { true }
|
||||
let(:user_can_perform_current_track_action) { true }
|
||||
let(:actions_completed) { { created_at: previous_action_completed_at, git_write_at: current_action_completed_at } }
|
||||
|
||||
|
|
@ -22,7 +21,6 @@ RSpec.describe Namespaces::InProductMarketingEmailsService, '#execute' do
|
|||
travel_to(frozen_time)
|
||||
create(:onboarding_progress, namespace: group, **actions_completed)
|
||||
group.add_developer(user)
|
||||
stub_experiment_for_subject(in_product_marketing_emails: experiment_enabled)
|
||||
allow(Ability).to receive(:allowed?).with(user, anything, anything).and_return(user_can_perform_current_track_action)
|
||||
allow(Notify).to receive(:in_product_marketing_email).and_return(double(deliver_later: nil))
|
||||
end
|
||||
|
|
@ -85,50 +83,6 @@ RSpec.describe Namespaces::InProductMarketingEmailsService, '#execute' do
|
|||
end
|
||||
end
|
||||
|
||||
describe 'experimentation' do
|
||||
context 'when on dotcom' do
|
||||
before do
|
||||
allow(::Gitlab).to receive(:com?).and_return(true)
|
||||
end
|
||||
|
||||
context 'when the experiment is enabled' do
|
||||
it 'adds the group as an experiment subject in the experimental group' do
|
||||
expect(Experiment).to receive(:add_group)
|
||||
.with(:in_product_marketing_emails, variant: :experimental, group: group)
|
||||
|
||||
execute_service
|
||||
end
|
||||
end
|
||||
|
||||
context 'when the experiment is disabled' do
|
||||
let(:experiment_enabled) { false }
|
||||
|
||||
it 'adds the group as an experiment subject in the control group' do
|
||||
expect(Experiment).to receive(:add_group)
|
||||
.with(:in_product_marketing_emails, variant: :control, group: group)
|
||||
|
||||
execute_service
|
||||
end
|
||||
|
||||
it { is_expected.not_to send_in_product_marketing_email }
|
||||
end
|
||||
|
||||
context 'when not on dotcom' do
|
||||
before do
|
||||
allow(::Gitlab).to receive(:com?).and_return(false)
|
||||
end
|
||||
|
||||
it 'does not add the group as an experiment subject' do
|
||||
expect(Experiment).not_to receive(:add_group)
|
||||
|
||||
execute_service
|
||||
end
|
||||
|
||||
it { is_expected.to send_in_product_marketing_email(user.id, group.id, :create, 0) }
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when the previous track action is not yet completed' do
|
||||
let(:previous_action_completed_at) { nil }
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +0,0 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
RSpec.shared_examples 'in-product marketing email' do
|
||||
before do
|
||||
stub_application_setting(in_product_marketing_emails_enabled: in_product_marketing_emails_enabled)
|
||||
stub_experiment(in_product_marketing_emails: experiment_active)
|
||||
allow(::Gitlab).to receive(:com?).and_return(is_gitlab_com)
|
||||
end
|
||||
|
||||
it 'executes the email service service' do
|
||||
expect(Namespaces::InProductMarketingEmailsService).to receive(:send_for_all_tracks_and_intervals).exactly(executes_service).times
|
||||
|
||||
subject.perform
|
||||
end
|
||||
end
|
||||
|
|
@ -2,38 +2,31 @@
|
|||
|
||||
require 'spec_helper'
|
||||
|
||||
RSpec.describe Namespaces::InProductMarketingEmailsWorker, '#perform' do
|
||||
using RSpec::Parameterized::TableSyntax
|
||||
|
||||
RSpec.describe Namespaces::InProductMarketingEmailsWorker, '#perform', unless: Gitlab.ee? do
|
||||
# Running this in EE would call the overridden method, which can't be tested in CE.
|
||||
# The EE code is covered in a separate EE spec.
|
||||
context 'not on gitlab.com', unless: Gitlab.ee? do
|
||||
let(:is_gitlab_com) { false }
|
||||
|
||||
where(:in_product_marketing_emails_enabled, :experiment_active, :executes_service) do
|
||||
true | true | 1
|
||||
true | false | 1
|
||||
false | false | 0
|
||||
false | true | 0
|
||||
context 'when the in_product_marketing_emails_enabled setting is disabled' do
|
||||
before do
|
||||
stub_application_setting(in_product_marketing_emails_enabled: false)
|
||||
end
|
||||
|
||||
with_them do
|
||||
it_behaves_like 'in-product marketing email'
|
||||
it 'does not execute the email service' do
|
||||
expect(Namespaces::InProductMarketingEmailsService).not_to receive(:send_for_all_tracks_and_intervals)
|
||||
|
||||
subject.perform
|
||||
end
|
||||
end
|
||||
|
||||
context 'on gitlab.com' do
|
||||
let(:is_gitlab_com) { true }
|
||||
|
||||
where(:in_product_marketing_emails_enabled, :experiment_active, :executes_service) do
|
||||
true | true | 1
|
||||
true | false | 0
|
||||
false | false | 0
|
||||
false | true | 0
|
||||
context 'when the in_product_marketing_emails_enabled setting is enabled' do
|
||||
before do
|
||||
stub_application_setting(in_product_marketing_emails_enabled: true)
|
||||
end
|
||||
|
||||
with_them do
|
||||
it_behaves_like 'in-product marketing email'
|
||||
it 'executes the email service' do
|
||||
expect(Namespaces::InProductMarketingEmailsService).to receive(:send_for_all_tracks_and_intervals)
|
||||
|
||||
subject.perform
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue