Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
e49bd57279
commit
dcdc526104
25 changed files with 132 additions and 92 deletions
|
|
@ -355,16 +355,19 @@ export default {
|
|||
</template>
|
||||
<template v-else>
|
||||
<div class="bold js-resolve-mr-widget-items-message">
|
||||
<gl-sprintf
|
||||
<div
|
||||
v-if="hasPipelineMustSucceedConflict"
|
||||
:message="pipelineMustSucceedConflictText"
|
||||
class="gl-display-flex gl-align-items-center"
|
||||
>
|
||||
<template #link="{ content }">
|
||||
<gl-link :href="mr.pipelineMustSucceedDocsPath" target="_blank">
|
||||
{{ content }}
|
||||
</gl-link>
|
||||
</template>
|
||||
</gl-sprintf>
|
||||
<gl-sprintf :message="pipelineMustSucceedConflictText" />
|
||||
<gl-link
|
||||
:href="mr.pipelineMustSucceedDocsPath"
|
||||
target="_blank"
|
||||
class="gl-display-flex gl-ml-2"
|
||||
>
|
||||
<gl-icon name="question" />
|
||||
</gl-link>
|
||||
</div>
|
||||
<gl-sprintf v-else :message="mergeDisabledText" />
|
||||
</div>
|
||||
</template>
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ import { __ } from '~/locale';
|
|||
|
||||
export const MERGE_DISABLED_TEXT = __('You can only merge once the items above are resolved.');
|
||||
export const PIPELINE_MUST_SUCCEED_CONFLICT_TEXT = __(
|
||||
'Pipelines must succeed for merge requests to be eligible to merge. Please enable pipelines for this project to continue. For more information, see the %{linkStart}documentation.%{linkEnd}',
|
||||
'A CI/CD pipeline must run and be successful before merge.',
|
||||
);
|
||||
|
||||
export default {
|
||||
|
|
|
|||
|
|
@ -348,6 +348,10 @@ $item-remove-button-space: 42px;
|
|||
|
||||
@media only screen and (min-width: 1500px) {
|
||||
.card-header {
|
||||
.health-label-short {
|
||||
display: none;
|
||||
}
|
||||
|
||||
.health-label-long {
|
||||
display: block;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -16,3 +16,5 @@ module IdeHelper
|
|||
}
|
||||
end
|
||||
end
|
||||
|
||||
::IdeHelper.prepend_if_ee('::EE::IdeHelper')
|
||||
|
|
|
|||
|
|
@ -337,7 +337,7 @@ module Clusters
|
|||
end
|
||||
|
||||
def local_tiller_enabled?
|
||||
Feature.enabled?(:managed_apps_local_tiller, clusterable, default_enabled: false)
|
||||
Feature.enabled?(:managed_apps_local_tiller, clusterable, default_enabled: true)
|
||||
end
|
||||
|
||||
private
|
||||
|
|
|
|||
|
|
@ -26,3 +26,6 @@
|
|||
= label_tag 'merge_request[squash]', class: 'form-check-label' do
|
||||
Squash commits when merge request is accepted.
|
||||
= link_to icon('question-circle'), help_page_path('user/project/merge_requests/squash_and_merge'), target: '_blank'
|
||||
- if project.squash_always?
|
||||
.gl-text-gray-600
|
||||
= _('Required in this project.')
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Resolve Misleading message displays when MR request is first submitted
|
||||
merge_request: 34958
|
||||
author:
|
||||
type: fixed
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Remove generic_alert_fingerprinting feature flag
|
||||
merge_request: 36148
|
||||
author:
|
||||
type: added
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Prevent duplicate health status text on epics
|
||||
merge_request:
|
||||
author:
|
||||
type: fixed
|
||||
5
changelogs/unreleased/add-alias-expansion-to-tf-docs.yml
Normal file
5
changelogs/unreleased/add-alias-expansion-to-tf-docs.yml
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add alias expansion to Terraform documentation
|
||||
merge_request: 35941
|
||||
author: zmeggyesi
|
||||
type: other
|
||||
5
changelogs/unreleased/use-local-tiller-by-default.yml
Normal file
5
changelogs/unreleased/use-local-tiller-by-default.yml
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Use local Tiller by default for GitLab-managed apps
|
||||
merge_request: 35562
|
||||
author:
|
||||
type: changed
|
||||
|
|
@ -314,7 +314,7 @@ The following documentation relates to the DevOps **Configure** stage:
|
|||
| [Create Kubernetes clusters](user/project/clusters/add_remove_clusters.md#create-new-cluster) | Use Kubernetes and GitLab. |
|
||||
| [Executable Runbooks](user/project/clusters/runbooks/index.md) | Documented procedures that explain how to carry out particular processes. |
|
||||
| [GitLab ChatOps](ci/chatops/README.md) | Interact with CI/CD jobs through chat services. |
|
||||
| [Installing Applications](user/project/clusters/index.md#installing-applications) | Deploy Helm, Ingress, and Prometheus on Kubernetes. |
|
||||
| [Installing Applications](user/project/clusters/index.md#installing-applications) | Install Helm charts such as Ingress and Prometheus on Kubernetes. |
|
||||
| [Mattermost slash commands](user/project/integrations/mattermost_slash_commands.md) | Enable and use slash commands from within Mattermost. |
|
||||
| [Multiple Kubernetes Clusters](user/project/clusters/index.md#multiple-kubernetes-clusters-premium) **(PREMIUM)** | Associate more than one Kubernetes clusters to your project. |
|
||||
| [Protected variables](ci/variables/README.md#protect-a-custom-variable) | Restrict variables to protected branches and tags. |
|
||||
|
|
|
|||
|
|
@ -279,8 +279,8 @@ To add a different cluster for each environment:
|
|||
1. Navigate to your project's **{cloud-gear}** **Operations > Kubernetes**.
|
||||
1. Create the Kubernetes clusters with their respective environment scope, as
|
||||
described from the table above.
|
||||
1. After creating the clusters, navigate to each cluster and install Helm Tiller
|
||||
and Ingress. Wait for the Ingress IP address to be assigned.
|
||||
1. After creating the clusters, navigate to each cluster and install
|
||||
Ingress. Wait for the Ingress IP address to be assigned.
|
||||
1. Make sure you've [configured your DNS](#auto-devops-base-domain) with the
|
||||
specified Auto DevOps domains.
|
||||
1. Navigate to each cluster's page, through **{cloud-gear}** **Operations > Kubernetes**,
|
||||
|
|
@ -301,9 +301,9 @@ No documented way of using private container registry with Auto DevOps exists.
|
|||
We strongly advise using GitLab Container Registry with Auto DevOps to
|
||||
simplify configuration and prevent any unforeseen issues.
|
||||
|
||||
### Installing Helm behind a proxy
|
||||
### Install applications behind a proxy
|
||||
|
||||
GitLab does not support installing [Helm as a GitLab-managed App](../../user/clusters/applications.md#helm) when
|
||||
GitLab's Helm integration does not support installing applications when
|
||||
behind a proxy. Users who want to do so must inject their proxy settings
|
||||
into the installation pods at runtime, such as by using a
|
||||
[`PodPreset`](https://kubernetes.io/docs/concepts/workloads/pods/podpreset/):
|
||||
|
|
|
|||
|
|
@ -98,24 +98,10 @@ status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
|
|||
Next, you will install some applications on your cluster that are needed
|
||||
to take full advantage of Auto DevOps.
|
||||
|
||||
## Install the package manager
|
||||
|
||||
After creating your Kubernetes cluster, GitLab's Kubernetes integration provides
|
||||
[pre-defined applications](../../user/project/clusters/index.md#installing-applications)
|
||||
for you to install. To install them, you must next install Helm Tiller, the
|
||||
Kubernetes package manager for Kubernetes, to enable the installation of other applications.
|
||||
|
||||
Next to **Helm Tiller**, click **Install**.
|
||||
|
||||
|
||||
|
||||
After installation completes, the page reloads, and you can install other
|
||||
applications.
|
||||
|
||||
## Install Ingress and Prometheus
|
||||
|
||||
After installing **Helm Tiller**, you can install other applications that rely on it,
|
||||
including Ingress and Prometheus, which we will install in this quick start guide:
|
||||
After your cluster is running, you can install your first applications.
|
||||
In this guide, we will install Ingress and Prometheus:
|
||||
|
||||
- Ingress - Provides load balancing, SSL termination, and name-based virtual hosting,
|
||||
using NGINX behind the scenes.
|
||||
|
|
|
|||
|
|
@ -92,7 +92,7 @@ status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
|
|||
The next step is to install some applications on your cluster that are needed
|
||||
to take full advantage of Auto DevOps.
|
||||
|
||||
## Installing Helm and Ingress
|
||||
## Install Ingress
|
||||
|
||||
GitLab's Kubernetes integration comes with some
|
||||
[pre-defined applications](../../user/project/clusters/index.md#installing-applications)
|
||||
|
|
@ -100,12 +100,6 @@ for you to install.
|
|||
|
||||
|
||||
|
||||
The first one to install is Helm Tiller, a package manager for Kubernetes, which
|
||||
is needed in order to install the rest of the applications. Go ahead and click
|
||||
its **Install** button.
|
||||
Once it is installed, the other applications that rely on it will each have their
|
||||
**Install** buttons enabled.
|
||||
|
||||
For this guide, we need to install Ingress. Ingress provides load balancing,
|
||||
SSL termination, and name-based virtual hosting, using NGINX behind
|
||||
the scenes. Make sure to switch the toogle to the enabled position before installing.
|
||||
|
|
|
|||
|
|
@ -32,8 +32,6 @@ To see a list of available applications to install. For a:
|
|||
- [Group-level cluster](../group/clusters/index.md), navigate to your group's
|
||||
**{cloud-gear}** **Kubernetes** page.
|
||||
|
||||
Install Helm first as it's used to install other applications.
|
||||
|
||||
NOTE: **Note:**
|
||||
As of GitLab 11.6, Helm will be upgraded to the latest version supported
|
||||
by GitLab before installing any of the applications.
|
||||
|
|
@ -71,32 +69,30 @@ can lead to confusion during deployments.
|
|||
|
||||
> - Introduced in GitLab 10.2 for project-level clusters.
|
||||
> - Introduced in GitLab 11.6 for group-level clusters.
|
||||
> - A local Tiller option was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2 behind a feature flag, disabled by default.
|
||||
> - A local Tiller option was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2 behind a feature flag, enabled by default.
|
||||
> - The feature flag for local Tiller is enabled on GitLab.com.
|
||||
|
||||
[Helm](https://helm.sh/docs/) is a package manager for Kubernetes and is
|
||||
required to install all the other applications. It is installed in its
|
||||
own pod inside the cluster which can run the `helm` CLI in a safe
|
||||
environment.
|
||||
used to install the GitLab-managed apps. GitLab runs each `helm` command
|
||||
in a pod within the `gitlab-managed-apps` namespace inside the cluster.
|
||||
|
||||
The [Tiller](https://v2.helm.sh/docs/glossary/#tiller) server used by Helm is
|
||||
installed into the `gitlab-managed-apps` namespace, but this is changing to
|
||||
instead use a *local Tiller* server. It can be enabled or disabled using the
|
||||
`managed_apps_local_tiller` feature flag. When the local Tiller feature is
|
||||
enabled, the Helm application does not need to be installed and will not be
|
||||
shown in the list of applications.
|
||||
As of GitLab 13.2, the integration uses a local
|
||||
[Tiller](https://v2.helm.sh/docs/glossary/#tiller) by default. When using a
|
||||
local Tiller, the Helm application does not need to be installed and will not
|
||||
be shown in the list of applications.
|
||||
|
||||
NOTE: **Note:**
|
||||
Installing Helm as a GitLab-managed App behind a proxy is not supported,
|
||||
but a [workaround](../../topics/autodevops/index.md#installing-helm-behind-a-proxy)
|
||||
GitLab's Helm integration does not support installing applications behind a proxy,
|
||||
but a [workaround](../../topics/autodevops/index.md#install-applications-behind-a-proxy)
|
||||
is available.
|
||||
|
||||
### Enable or disable local Tiller **(CORE ONLY)**
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2
|
||||
> - The option to disable local Tiller is [planned for removal](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.3
|
||||
|
||||
Local Tiller is under development, but is ready for production use. It is
|
||||
deployed behind a feature flag that is **disabled by default**.
|
||||
deployed behind a feature flag that is **enabled by default**.
|
||||
[GitLab administrators with access to the GitLab Rails console](../../administration/feature_flags.md)
|
||||
can enable it for your instance.
|
||||
|
||||
|
|
|
|||
|
|
@ -220,6 +220,18 @@ can configure this manually as follows:
|
|||
- alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
In distributions that use Bash (for example, Ubuntu), `alias` statements are not
|
||||
expanded in non-interactive mode. If your pipelines fail with the error
|
||||
`convert_report: command not found`, alias expansion can be activated explicitly
|
||||
by adding a `shopt` command to your script:
|
||||
|
||||
```yaml
|
||||
before_script:
|
||||
- shopt -s expand_aliases
|
||||
- alias convert_report="jq -r '([.resource_changes[]?.change.actions?]|flatten)|{\"create\":(map(select(.==\"create\"))|length),\"update\":(map(select(.==\"update\"))|length),\"delete\":(map(select(.==\"delete\"))|length)}'"
|
||||
```
|
||||
|
||||
1. Define a `script` that runs `terraform plan` and `terraform show`. These commands
|
||||
pipe the output and convert the relevant bits into a store variable `PLAN_JSON`.
|
||||
This JSON is used to create a
|
||||
|
|
|
|||
|
|
@ -57,14 +57,10 @@ to manage the newly created cluster.
|
|||
NOTE: **Note:**
|
||||
Restricted service account for deployment was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) in GitLab 11.5.
|
||||
|
||||
When you install Helm into your cluster, the `tiller` service account
|
||||
is created with `cluster-admin` privileges in the `gitlab-managed-apps`
|
||||
namespace.
|
||||
|
||||
This service account will be:
|
||||
|
||||
- Added to the installed Helm Tiller.
|
||||
- Used by Helm to install and run [GitLab managed applications](index.md#installing-applications).
|
||||
The first time you install an application into your cluster, the `tiller` service
|
||||
account is created with `cluster-admin` privileges in the
|
||||
`gitlab-managed-apps` namespace. This service account will be used by Helm to
|
||||
install and run [GitLab managed applications](index.md#installing-applications).
|
||||
|
||||
Helm will also create additional service accounts and other resources for each
|
||||
installed application. Consult the documentation of the Helm charts for each application
|
||||
|
|
@ -93,8 +89,8 @@ GitLab creates the following resources for RBAC clusters.
|
|||
| `gitlab` | `ServiceAccount` | `default` namespace | Creating a new cluster |
|
||||
| `gitlab-admin` | `ClusterRoleBinding` | [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) roleRef | Creating a new cluster |
|
||||
| `gitlab-token` | `Secret` | Token for `gitlab` ServiceAccount | Creating a new cluster |
|
||||
| `tiller` | `ServiceAccount` | `gitlab-managed-apps` namespace | Installing Helm Tiller |
|
||||
| `tiller-admin` | `ClusterRoleBinding` | `cluster-admin` roleRef | Installing Helm Tiller |
|
||||
| `tiller` | `ServiceAccount` | `gitlab-managed-apps` namespace | Installing Helm charts |
|
||||
| `tiller-admin` | `ClusterRoleBinding` | `cluster-admin` roleRef | Installing Helm charts |
|
||||
| Environment namespace | `Namespace` | Contains all environment-specific resources | Deploying to a cluster |
|
||||
| Environment namespace | `ServiceAccount` | Uses namespace of environment | Deploying to a cluster |
|
||||
| Environment namespace | `Secret` | Token for environment ServiceAccount | Deploying to a cluster |
|
||||
|
|
@ -108,8 +104,8 @@ GitLab creates the following resources for ABAC clusters.
|
|||
|:----------------------|:---------------------|:-------------------------------------|:---------------------------|
|
||||
| `gitlab` | `ServiceAccount` | `default` namespace | Creating a new cluster |
|
||||
| `gitlab-token` | `Secret` | Token for `gitlab` ServiceAccount | Creating a new cluster |
|
||||
| `tiller` | `ServiceAccount` | `gitlab-managed-apps` namespace | Installing Helm Tiller |
|
||||
| `tiller-admin` | `ClusterRoleBinding` | `cluster-admin` roleRef | Installing Helm Tiller |
|
||||
| `tiller` | `ServiceAccount` | `gitlab-managed-apps` namespace | Installing Helm charts |
|
||||
| `tiller-admin` | `ClusterRoleBinding` | `cluster-admin` roleRef | Installing Helm charts |
|
||||
| Environment namespace | `Namespace` | Contains all environment-specific resources | Deploying to a cluster |
|
||||
| Environment namespace | `ServiceAccount` | Uses namespace of environment | Deploying to a cluster |
|
||||
| Environment namespace | `Secret` | Token for environment ServiceAccount | Deploying to a cluster |
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 70 KiB |
|
|
@ -42,9 +42,6 @@ To create an executable runbook, you will need:
|
|||
- **Kubernetes** - A Kubernetes cluster is required to deploy the rest of the
|
||||
applications. The simplest way to get started is to add a cluster using one
|
||||
of [GitLab's integrations](../add_remove_clusters.md#create-new-cluster).
|
||||
- **Helm Tiller** - Helm is a package manager for Kubernetes and is required to
|
||||
install all the other applications. It's installed in its own pod inside the
|
||||
cluster which can run the Helm CLI in a safe environment.
|
||||
- **Ingress** - Ingress can provide load balancing, SSL termination, and name-based
|
||||
virtual hosting. It acts as a web proxy for your applications.
|
||||
- **JupyterHub** - [JupyterHub](https://jupyterhub.readthedocs.io/) is a multi-user
|
||||
|
|
@ -68,13 +65,8 @@ the components outlined above and the pre-loaded demo runbook.
|
|||
|
||||
1. Add a Kubernetes cluster to your project by following the steps outlined in
|
||||
[Create new cluster](../add_remove_clusters.md#create-new-cluster).
|
||||
1. After the cluster has been provisioned in GKE, click the **Install** button
|
||||
next to the **Helm Tiller** application to install Helm Tiller.
|
||||
|
||||
|
||||
|
||||
1. After Helm Tiller has been installed successfully, click the **Install** button next
|
||||
to the **Ingress** application.
|
||||
1. Click the **Install** button next to the **Ingress** application to install Ingress.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -51,8 +51,6 @@ To run Knative on GitLab, you will need:
|
|||
1. **Kubernetes Cluster:** An RBAC-enabled Kubernetes cluster is required to deploy Knative.
|
||||
The simplest way to get started is to add a cluster using GitLab's [GKE integration](../add_remove_clusters.md).
|
||||
The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory.
|
||||
1. **Helm Tiller:** Helm is a package manager for Kubernetes and is required to install
|
||||
Knative.
|
||||
1. **GitLab Runner:** A runner is required to run the CI jobs that will deploy serverless
|
||||
applications or functions onto your cluster. You can install the GitLab Runner
|
||||
onto the existing Kubernetes cluster. See [Installing Applications](../index.md#installing-applications) for more information.
|
||||
|
|
@ -80,8 +78,8 @@ To run Knative on GitLab, you will need:
|
|||
NOTE: **Note:**
|
||||
The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB memory. **RBAC must be enabled.**
|
||||
|
||||
1. [Add a Kubernetes cluster](../add_remove_clusters.md) and [install Helm](../index.md#installing-applications).
|
||||
1. Once Helm has been successfully installed, scroll down to the Knative app section. Enter the domain to be used with
|
||||
1. [Add a Kubernetes cluster](../add_remove_clusters.md).
|
||||
1. Select the **Applications** tab and scroll down to the Knative app section. Enter the domain to be used with
|
||||
your application/functions (e.g. `example.com`) and click **Install**.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -32,11 +32,10 @@ GitLab can seamlessly deploy and manage Prometheus on a [connected Kubernetes cl
|
|||
#### Requirements
|
||||
|
||||
- A [connected Kubernetes cluster](../clusters/index.md)
|
||||
- Helm Tiller [installed by GitLab](../clusters/index.md#installing-applications)
|
||||
|
||||
#### Getting started
|
||||
|
||||
Once you have a connected Kubernetes cluster with Helm installed, deploying a managed Prometheus is as easy as a single click.
|
||||
Once you have a connected Kubernetes cluster, deploying a managed Prometheus is as easy as a single click.
|
||||
|
||||
1. Go to the **Operations > Kubernetes** page to view your connected clusters
|
||||
1. Select the cluster you would like to deploy Prometheus to
|
||||
|
|
@ -51,7 +50,7 @@ After completing the steps above, you will also need deployments in order to vie
|
|||
will help you to quickly create a deployment:
|
||||
|
||||
1. Navigate to your project's **Operations > Kubernetes** page, and ensure that,
|
||||
in addition to "Prometheus" and "Helm Tiller", you also have "Runner" and "Ingress"
|
||||
in addition to "Prometheus", you also have "Runner" and "Ingress"
|
||||
installed. Once "Ingress" is installed, copy its endpoint.
|
||||
1. Navigate to your project's **Settings > CI/CD** page. In the Auto DevOps section,
|
||||
select a deployment strategy and save your changes.
|
||||
|
|
|
|||
|
|
@ -1008,6 +1008,9 @@ msgstr ""
|
|||
msgid "A .NET Core console application template, customizable for any .NET Core project"
|
||||
msgstr ""
|
||||
|
||||
msgid "A CI/CD pipeline must run and be successful before merge."
|
||||
msgstr ""
|
||||
|
||||
msgid "A GitBook site that uses Netlify for CI/CD instead of GitLab, but still with all the other great GitLab features."
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -16627,9 +16630,6 @@ msgstr ""
|
|||
msgid "Pipelines for merge requests are configured. A detached pipeline runs in the context of the merge request, and not against the merged result. Learn more in the documentation for Pipelines for Merged Results."
|
||||
msgstr ""
|
||||
|
||||
msgid "Pipelines must succeed for merge requests to be eligible to merge. Please enable pipelines for this project to continue. For more information, see the %{linkStart}documentation.%{linkEnd}"
|
||||
msgstr ""
|
||||
|
||||
msgid "Pipelines settings for '%{project_name}' were successfully updated."
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -177,23 +177,19 @@ RSpec.shared_examples "installing applications for a cluster" do |managed_apps_l
|
|||
end
|
||||
|
||||
it 'shows status transition' do
|
||||
def email_form_value
|
||||
page.find('.js-email').value
|
||||
end
|
||||
|
||||
page.within('.js-cluster-application-row-cert_manager') do
|
||||
expect(email_form_value).to eq(cluster.user.email)
|
||||
expect(page).to have_field('Issuer Email', with: cluster.user.email)
|
||||
expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
|
||||
|
||||
page.find('.js-email').set("new_email@example.org")
|
||||
Clusters::Cluster.last.application_cert_manager.make_installing!
|
||||
|
||||
expect(email_form_value).to eq('new_email@example.org')
|
||||
expect(page).to have_field('Issuer Email', with: 'new_email@example.org')
|
||||
expect(page).to have_css('.js-cluster-application-install-button', exact_text: 'Installing')
|
||||
|
||||
Clusters::Cluster.last.application_cert_manager.make_installed!
|
||||
|
||||
expect(email_form_value).to eq('new_email@example.org')
|
||||
expect(page).to have_field('Issuer Email', with: 'new_email@example.org')
|
||||
expect(page).to have_css('.js-cluster-application-uninstall-button', exact_text: 'Uninstall')
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -16,6 +16,40 @@ RSpec.describe 'User edits a merge request', :js do
|
|||
visit(edit_project_merge_request_path(project, merge_request))
|
||||
end
|
||||
|
||||
describe 'Squash commits' do
|
||||
it 'displays "Required in this project" for "Required" project setting squash option' do
|
||||
project.project_setting.update!(squash_option: 'always')
|
||||
visit(edit_project_merge_request_path(project, merge_request))
|
||||
|
||||
expect(page).to have_content('Squash commits when merge request is accepted.')
|
||||
expect(page).to have_content("Required in this project")
|
||||
end
|
||||
|
||||
it 'does not display message for "Allow" project setting squash option' do
|
||||
project.project_setting.update!(squash_option: 'default_off')
|
||||
visit(edit_project_merge_request_path(project, merge_request))
|
||||
|
||||
expect(page).to have_content('Squash commits when merge request is accepted.')
|
||||
expect(page).not_to have_content("Required in this project")
|
||||
end
|
||||
|
||||
it 'does not display message for "Encourage" project setting squash option' do
|
||||
project.project_setting.update!(squash_option: 'default_on')
|
||||
visit(edit_project_merge_request_path(project, merge_request))
|
||||
|
||||
expect(page).to have_content('Squash commits when merge request is accepted.')
|
||||
expect(page).not_to have_content("Required in this project")
|
||||
end
|
||||
|
||||
it 'is hidden for "Do not allow" project setting squash option' do
|
||||
project.project_setting.update!(squash_option: 'never')
|
||||
visit(edit_project_merge_request_path(project, merge_request))
|
||||
|
||||
expect(page).not_to have_content('Squash commits when merge request is accepted.')
|
||||
expect(page).not_to have_css('#merge_request_squash')
|
||||
end
|
||||
end
|
||||
|
||||
it 'changes the target branch' do
|
||||
expect(page).to have_content('From master into feature')
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue