Commit 784ab270 authored by GitLab Bot's avatar GitLab Bot

Merge remote-tracking branch 'upstream/master' into ce-to-ee-2018-11-13

# Conflicts:
#	app/models/identity/uniqueness_scopes.rb
#	doc/ci/examples/browser_performance.md
#	doc/ci/examples/code_quality.md
#	doc/ci/examples/container_scanning.md
#	doc/ci/examples/dast.md
#	doc/ci/yaml/README.md

[ci skip]
parents 0b821f02 24971b5b
<script>
import { GlTooltipDirective, GlLink, GlButton } from '@gitlab-org/gitlab-ui';
import CiIconBadge from './ci_badge_link.vue';
import TimeagoTooltip from './time_ago_tooltip.vue';
import tooltip from '../directives/tooltip';
import UserAvatarImage from './user_avatar/user_avatar_image.vue';
import LoadingButton from '~/vue_shared/components/loading_button.vue';
/**
* Renders header component for job and pipeline page based on UI mockups
......@@ -16,9 +17,12 @@ export default {
CiIconBadge,
TimeagoTooltip,
UserAvatarImage,
GlLink,
GlButton,
LoadingButton,
},
directives: {
tooltip,
GlTooltip: GlTooltipDirective,
},
props: {
status: {
......@@ -98,8 +102,8 @@ export default {
by
<template v-if="user">
<a
v-tooltip
<gl-link
v-gl-tooltip
:href="user.path"
:title="user.email"
class="js-user-link commit-committer-link"
......@@ -113,7 +117,7 @@ export default {
/>
{{ user.name }}
</a>
</gl-link>
<span
v-if="user.status_tooltip_html"
v-html="user.status_tooltip_html"></span>
......@@ -127,16 +131,16 @@ export default {
<template
v-for="(action, i) in actions"
>
<a
<gl-link
v-if="action.type === 'link'"
:key="i"
:href="action.path"
:class="action.cssClass"
>
{{ action.label }}
</a>
</gl-link>
<a
<gl-link
v-else-if="action.type === 'ujs-link'"
:key="i"
:href="action.path"
......@@ -145,31 +149,24 @@ export default {
rel="nofollow"
>
{{ action.label }}
</a>
</gl-link>
<button
<loading-button
v-else-if="action.type === 'button'"
:key="i"
:loading="action.isLoading"
:disabled="action.isLoading"
:class="action.cssClass"
type="button"
container-class="d-inline"
:label="action.label"
@click="onClickAction(action)"
>
{{ action.label }}
<i
v-show="action.isLoading"
class="fa fa-spin fa-spinner"
aria-hidden="true"
>
</i>
</button>
/>
</template>
</section>
<button
<gl-button
v-if="hasSidebarButton"
id="toggleSidebar"
type="button"
class="btn btn-default d-block d-sm-none
class="d-block d-sm-none
sidebar-toggle-btn js-sidebar-build-toggle js-sidebar-build-toggle-header"
@click="onClickSidebarButton"
>
......@@ -179,6 +176,6 @@ sidebar-toggle-btn js-sidebar-build-toggle js-sidebar-build-toggle-header"
aria-labelledby="toggleSidebar"
>
</i>
</button>
</gl-button>
</header>
</template>
......@@ -9,5 +9,8 @@ class Identity < ActiveRecord::Base
end
end
end
<<<<<<< HEAD
Identity::UniquenessScopes.prepend(EE::Identity::UniquenessScopes)
=======
>>>>>>> upstream/master
......@@ -37,6 +37,6 @@
= link_to 'Reopen', merge_request_path(@merge_request, merge_request: { state_event: :reopen }), method: :put, class: 'reopen-mr-link', title: 'Reopen merge request'
- if can_update_merge_request
= link_to 'Edit', edit_project_merge_request_path(@project, @merge_request), class: "d-none d-sm-none d-md-block btn btn-grouped js-issuable-edit"
= link_to 'Edit', edit_project_merge_request_path(@project, @merge_request), class: "d-none d-sm-none d-md-block btn btn-grouped js-issuable-edit qa-edit-button"
= render 'shared/issuable/close_reopen_button', issuable: @merge_request, can_update: can_update_merge_request, can_reopen: can_update_merge_request
......@@ -41,7 +41,11 @@ The above example will create a `performance` job in your CI/CD pipeline and wil
Sitespeed.io against the webpage you defined in `URL` to gather key metrics.
The [GitLab plugin](https://gitlab.com/gitlab-org/gl-performance) for
Sitespeed.io is downloaded in order to save the report as a
<<<<<<< HEAD
[Performance report artifact](../../ci/yaml/README.md#artifactsreportsperformance)
=======
[Performance report artifact](https://docs.gitlab.com/ee//ci/yaml/README.html#artifactsreportsperformance)
>>>>>>> upstream/master
that you can later download and analyze.
Due to implementation limitations we always take the latest Performance artifact available.
......@@ -55,8 +59,13 @@ provide a list of URLs to test, please consult
TIP: **Tip:**
For [GitLab Premium](https://about.gitlab.com/pricing/) users, key metrics are automatically
<<<<<<< HEAD
extracted and shown right in the merge request widget. Learn more about
[Browser Performance Testing](../../user/project/merge_requests/browser_performance_testing.md).
=======
extracted and shown right in the merge request widget.
[Learn more on Browser Performance Testing in merge requests](https://docs.gitlab.com/ee//user/project/merge_requests/browser_performance_testing.html).
>>>>>>> upstream/master
## Performance testing on Review Apps
......
......@@ -43,8 +43,14 @@ Due to implementation limitations we always take the latest Code Quality artifac
TIP: **Tip:**
For [GitLab Starter][ee] users, this information will be automatically
extracted and shown right in the merge request widget.
<<<<<<< HEAD
[Learn more on Code Quality in merge requests](../../user/project/merge_requests/code_quality.html).
## Previous job definitions
=======
[Learn more on Code Quality in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html).
>>>>>>> upstream/master
## Previous job definitions
CAUTION: **Caution:**
......@@ -75,9 +81,16 @@ code_quality:
paths: [gl-code-quality-report.json]
```
<<<<<<< HEAD
Alternatively the job name could be `codeclimate` or `codequality` and the artifact name could be
`codeclimate.json`. These names have been deprecated with GitLab 11.0 and may be removed
in next major release, GitLab 12.0.
=======
Alternatively the job name could be `codeclimate` or `codequality`
and the artifact name could be `codeclimate.json`.
These names have been deprecated with GitLab 11.0
and may be removed in next major release, GitLab 12.0.
>>>>>>> upstream/master
For GitLab 10.3 and earlier, the job should look like:
......
......@@ -51,7 +51,11 @@ The above example will create a `container_scanning` job in your CI/CD pipeline,
the image from the [Container Registry](../../user/project/container_registry.md)
(whose name is defined from the two `CI_APPLICATION_` variables) and scan it
for possible vulnerabilities. The report will be saved as a
<<<<<<< HEAD
[Container Scanning report artifact](../../ci/yaml/README.md#artifactsreportscontainer_scanning)
=======
[Container Scanning report artifact](https://docs.gitlab.com/ee//ci/yaml/README.html#artifactsreportscontainer_scanning)
>>>>>>> upstream/master
that you can later download and analyze.
Due to implementation limitations we always take the latest Container Scanning artifact available.
......@@ -62,7 +66,11 @@ in our case its named `clair-whitelist.yml`.
TIP: **Tip:**
For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget.
<<<<<<< HEAD
[Learn more on Container Scanning in merge requests](../../user/project/merge_requests/container_scanning.html).
=======
[Learn more on Container Scanning in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/container_scanning.html).
>>>>>>> upstream/master
CAUTION: **Caution:**
Starting with GitLab 11.5, Container Scanning feature is licensed under the name `container_scanning`.
......
......@@ -17,7 +17,11 @@ It can be very useful combined with [Review Apps](../review_apps/index.md).
## Example
First, you need GitLab Runner with
<<<<<<< HEAD
[docker executor](https://docs.gitlab.com/runner/executors/docker.html).
=======
[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
>>>>>>> upstream/master
Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
generates the expected report:
......@@ -40,7 +44,11 @@ dast:
The above example will create a `dast` job in your CI/CD pipeline which will run
the tests on the URL defined in the `website` variable (change it to use your
own) and scan it for possible vulnerabilities. The report will be saved as a
<<<<<<< HEAD
[DAST report artifact](../../ci/yaml/README.md#artifactsreportsdast)
=======
[DAST report artifact](https://docs.gitlab.com/ee//ci/yaml/README.html#artifactsreportsdast)
>>>>>>> upstream/master
that you can later download and analyze.
Due to implementation limitations we always take the latest DAST artifact available.
......@@ -72,7 +80,11 @@ to learn more about authentication settings.
TIP: **Tip:**
For [GitLab Ultimate][ee] users, this information will
be automatically extracted and shown right in the merge request widget.
<<<<<<< HEAD
[Learn more on DAST in merge requests](../../user/project/merge_requests/dast.md).
=======
[Learn more on DAST in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/dast.html).
>>>>>>> upstream/master
## Previous job definitions
......
......@@ -1337,7 +1337,11 @@ concatenated into a single file. Use a filename pattern (`junit: rspec-*.xml`),
an array of filenames (`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`), or a
combination thereof (`junit: [rspec.xml, test-results/TEST-*.xml]`).
<<<<<<< HEAD
#### `artifacts:reports:codequality`
=======
#### `artifacts:reports:codequality` **[STARTER]**
>>>>>>> upstream/master
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
......@@ -1347,7 +1351,11 @@ as artifacts.
The collected Code Quality report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests.
<<<<<<< HEAD
#### `artifacts:reports:sast`
=======
#### `artifacts:reports:sast` **[ULTIMATE]**
>>>>>>> upstream/master
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
......@@ -1358,7 +1366,11 @@ The collected SAST report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
<<<<<<< HEAD
#### `artifacts:reports:dependency_scanning`
=======
#### `artifacts:reports:dependency_scanning` **[ULTIMATE]**
>>>>>>> upstream/master
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
......@@ -1369,7 +1381,11 @@ The collected Dependency Scanning report will be uploaded to GitLab as an artifa
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
<<<<<<< HEAD
#### `artifacts:reports:container_scanning`
=======
#### `artifacts:reports:container_scanning` **[ULTIMATE]**
>>>>>>> upstream/master
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
......@@ -1380,7 +1396,11 @@ The collected Container Scanning report will be uploaded to GitLab as an artifac
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
<<<<<<< HEAD
#### `artifacts:reports:dast`
=======
#### `artifacts:reports:dast` **[ULTIMATE]**
>>>>>>> upstream/master
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
......@@ -1391,7 +1411,11 @@ The collected DAST report will be uploaded to GitLab as an artifact and will
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
<<<<<<< HEAD
#### `artifacts:reports:license_management`
=======
#### `artifacts:reports:license_management` **[ULTIMATE]**
>>>>>>> upstream/master
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
......@@ -1402,7 +1426,11 @@ The collected License Management report will be uploaded to GitLab as an artifac
be automatically shown in merge requests, pipeline view and provide data for security
dashboards.
<<<<<<< HEAD
#### `artifacts:reports:performance`
=======
#### `artifacts:reports:performance` **[PREMIUM]**
>>>>>>> upstream/master
> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
......
......@@ -119,10 +119,20 @@ This also applies to views.
### EE features based on CE features
For features that build on existing CE features, write a module in the
`EE` namespace and `prepend` it in the CE class. This makes conflicts
less likely to happen during CE to EE merges because only one line is
added to the CE class - the `prepend` line.
For features that build on existing CE features, write a module in the `EE`
namespace and `prepend` it in the CE class, on the last line of the file that
the class resides in. This makes conflicts less likely to happen during CE to EE
merges because only one line is added to the CE class - the `prepend` line. For
example, to prepend a module into the `User` class you would use the following
approach:
```ruby
class User < ActiveRecord::Base
# ... lots of code here ...
end
User.prepend(EE::User)
```
Since the module would require an `EE` namespace, the file should also be
put in an `ee/` sub-directory. For example, we want to extend the user model
......@@ -231,7 +241,6 @@ the existing file:
```ruby
class ApplicationController < ActionController::Base
prepend EE::ApplicationController
# ...
def after_sign_out_path_for(resource)
......@@ -240,6 +249,8 @@ class ApplicationController < ActionController::Base
# ...
end
ApplicationController.prepend(EE::ApplicationController)
```
And create a new file in the `ee/` sub-directory with the altered
......@@ -533,8 +544,6 @@ module API
end
end
prepend EE::API::MergeRequests
params :optional_params do
# CE specific params go here...
......@@ -542,6 +551,8 @@ module API
end
end
end
API::MergeRequests.prepend(EE::API::MergeRequests)
```
And then we could override it in EE module:
......@@ -582,10 +593,10 @@ module API
authorize_read_builds!
end
end
prepend EE::API::JobArtifacts
end
end
API::JobArtifacts.prepend(EE::API::JobArtifacts)
```
And then we can follow regular object-oriented practices to override it:
......@@ -626,8 +637,6 @@ module API
end
end
prepend EE::API::MergeRequests
put ':id/merge_requests/:merge_request_iid/merge' do
merge_request = find_project_merge_request(params[:merge_request_iid])
......@@ -639,6 +648,8 @@ module API
end
end
end
API::MergeRequests.prepend(EE::API::MergeRequests)
```
Note that `update_merge_request_ee` doesn't do anything in CE, but
......@@ -676,27 +687,37 @@ or not we really need to extend it from EE. For now we're not using it much.
Sometimes we need to use different arguments for a particular API route, and we
can't easily extend it with an EE module because Grape has different context in
different blocks. In order to overcome this, we could use class methods from the
API class.
different blocks. In order to overcome this, we need to move the data to a class
method that resides in a separate module or class. This allows us to extend that
module or class before its data is used, without having to place a `prepend` in
the middle of CE code.
For example, in one place we need to pass an extra argument to
`at_least_one_of` so that the API could consider an EE-only argument as the
least argument. This is not quite beautiful but it's working:
least argument. We would approach this as follows:
```ruby
# api/merge_requests/parameters.rb
module API
class MergeRequests < Grape::API
def self.update_params_at_least_one_of
%i[
assignee_id
description
]
module Parameters
def self.update_params_at_least_one_of
%i[
assignee_id
description
]
end
end
end
end
prepend EE::API::MergeRequests
API::MergeRequests::Parameters.prepend(EE::API::MergeRequests::Parameters)
# api/merge_requests.rb
module API
class MergeRequests < Grape::API
params do
at_least_one_of(*::API::MergeRequests.update_params_at_least_one_of)
at_least_one_of(*Parameters.update_params_at_least_one_of)
end
end
end
......@@ -708,16 +729,18 @@ And then we could easily extend that argument in the EE class method:
module EE
module API
module MergeRequests
extend ActiveSupport::Concern
module Parameters
extend ActiveSupport::Concern
class_methods do
extend ::Gitlab::Utils::Override
class_methods do
extend ::Gitlab::Utils::Override
override :update_params_at_least_one_of
def update_params_at_least_one_of
super.push(*%i[
squash
])
override :update_params_at_least_one_of
def update_params_at_least_one_of
super.push(*%i[
squash
])
end
end
end
end
......@@ -728,6 +751,78 @@ end
It could be annoying if we need this for a lot of routes, but it might be the
simplest solution right now.
This approach can also be used when models define validations that depend on
class methods. For example:
```ruby
# app/models/identity.rb
class Identity < ActiveRecord::Base
def self.uniqueness_scope
[:provider]
end
prepend EE::Identity
validates :extern_uid,
allow_blank: true,
uniqueness: { scope: uniqueness_scope, case_sensitive: false }
end
# ee/app/models/ee/identity.rb
module EE
module Identity
extend ActiveSupport::Concern
class_methods do
extend ::Gitlab::Utils::Override
def uniqueness_scope
[*super, :saml_provider_id]
end
end
end
end
```
Instead of taking this approach, we would refactor our code into the following:
```ruby
# ee/app/models/ee/identity/uniqueness_scopes.rb
module EE
module Identity
module UniquenessScopes
extend ActiveSupport::Concern
class_methods do
extend ::Gitlab::Utils::Override
def uniqueness_scope
[*super, :saml_provider_id]
end
end
end
end
end
# app/models/identity/uniqueness_scopes.rb
class Identity < ActiveRecord::Base
module UniquenessScopes
def self.uniqueness_scope
[:provider]
end
end
end
Identity::UniquenessScopes.prepend(EE::Identity::UniquenessScopes)
# app/models/identity.rb
class Identity < ActiveRecord::Base
validates :extern_uid,
allow_blank: true,
uniqueness: { scope: Identity::UniquenessScopes.scopes, case_sensitive: false }
end
```
### Code in `spec/`
When you're testing EE-only features, avoid adding examples to the
......
......@@ -2,7 +2,7 @@
## Monitoring
We have a performance dashboard available in one of our [grafana instances](https://performance.gprd.gitlab.com/dashboard/db/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://sitespeed.io) every 6 hours. These changes are displayed after a set number of pages are aggregated.
We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://sitespeed.io) every 6 hours. These changes are displayed after a set number of pages are aggregated.
These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/team) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
......
---
author: Joshua Lambert
author_gitlab: joshlambert
level: intermediate
article_type: tutorial
date: 2018-06-05
---
# Connecting and deploying to an Amazon EKS cluster
## Introduction
In this tutorial, we will show how easy it is to integrate an [Amazon EKS](https://aws.amazon.com/eks/) cluster with GitLab, and begin deploying applications.
In this tutorial, we will show how to integrate an [Amazon EKS](https://aws.amazon.com/eks/) cluster with GitLab, and begin deploying applications.
For an end-to-end walkthrough we will:
......@@ -21,7 +13,7 @@ For an end-to-end walkthrough we will:
You will need:
1. An account on GitLab, like [GitLab.com](https://gitlab.com)
1. An Amazon EKS cluster
1. An Amazon EKS cluster (with worker nodes properly configured)
1. `kubectl` [installed and configured for access to the EKS cluster](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#get-started-kubectl)
If you don't have an Amazon EKS cluster, one can be created by following [the EKS getting started guide](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).
......@@ -38,26 +30,103 @@ Give the project a name, and then select `Create project`.
![Create Project](img/create_project.png)
## Connecting the EKS cluster
## Configuring and connecting the EKS cluster
From the left side bar, hover over `Operations` and select `Kubernetes`, then click on `Add Kubernetes cluster`, and finally `Add an existing Kubernetes cluster`.
A few details from the EKS cluster will be required to connect it to GitLab.
1. A valid Kubernetes certificate and token are needed to authenticate to the EKS cluster. A pair is created by default, which can be used. Open a shell and use `kubectl` to retrieve them:
* List the secrets with `kubectl get secrets`, and one should named similar to `default-token-xxxxx`. Copy that token name for use below.
* Get the certificate with `kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 -D`
* Retrieve the token with `kubectl get secret <secret name> -o jsonpath="{['data']['token']}" | base64 -D`.
1. **Retrieve the certificate**: A valid Kubernetes certificate is needed to authenticate to the EKS cluster. We will use the certificate created by default. Open a shell and use `kubectl` to retrieve it:
- List the secrets with `kubectl get secrets`, and one should named similar to `default-token-xxxxx`. Copy that token name for use below.
- Get the certificate with `kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 -D`
1. **Create admin token**: A `cluster-admin` token is required to install and manage Helm Tiller. GitLab establishes mutual SSL auth with Helm Tiller and creates limited service accounts for each application. To create the token we will create an admin service account as follows:
1. Create a file called `eks-admin-service-account.yaml` with the text below:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-admin
namespace: kube-system
```
2. Apply the service account to your cluster:
```bash
kubectl apply -f eks-admin-service-account.yaml
```
Output:
```bash
serviceaccount "eks-admin" created
```
3. Create a file called `eks-admin-cluster-role-binding.yaml` with the text below:
```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: eks-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: eks-admin
namespace: kube-system
```
4. Apply the cluster role binding to your cluster:
```bash
kubectl apply -f eks-admin-cluster-role-binding.yaml
```
Output:
```bash
clusterrolebinding "eks-admin" created
```
5. Retrieve the token for the `eks-admin` service account. Copy the `<authentication_token>` value from the output.
```bash
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')
```
Output:
```yaml
Name: eks-admin-token-b5zv4
Namespace: kube-system
Labels: <none>
Annotations: kubernetes.io/service-account.name=eks-admin
kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1025 bytes
namespace: 11 bytes
token: <authentication_token>
```
1. The API server endpoint is also required, so GitLab can connect to the cluster. This is displayed on the AWS EKS console, when viewing the EKS cluster details.
You now have all the information needed to connect the EKS cluster:
* Kubernetes cluster name: Provide a name for the cluster to identify it within GitLab.
* Environment scope: Leave this as `*` for now, since we are only connecting a single cluster.
* API URL: Paste in the API server endpoint retrieved above.
* CA Certificate: Paste the certificate data from the earlier step, as-is.
* Paste the token value.
* Project namespace: This can be left blank to accept the default namespace, based on the project name.
- Kubernetes cluster name: Provide a name for the cluster to identify it within GitLab.
- Environment scope: Leave this as `*` for now, since we are only connecting a single cluster.
- API URL: Paste in the API server endpoint retrieved above.
- CA Certificate: Paste the certificate data from the earlier step, as-is.
- Paste the admin token value.
- Project namespace: This can be left blank to accept the default namespace, based on the project name.
![Add Cluster](img/add_cluster.png)
......@@ -65,9 +134,11 @@ Click on `Add Kubernetes cluster`, the cluster is now connected to GitLab. At th
If you would like to utilize your own CI/CD scripts to deploy to the cluster, you can stop here.
## Disable Role-Based Access Control (RBAC)
## Disable Role-Based Access Control (RBAC) - Optional
When connecting a cluster via GitLab integration, you may specify whether the cluster is RBAC-enabled or not. This will affect how GitLab interacts with the cluster for certain operations. If you **did not** check the "RBAC-enabled cluster" checkbox at creation time, GitLab will assume RBAC is disabled for your cluster when interacting with it. If so, you must disable RBAC on your cluster for the integration to work properly.
Presently, Auto DevOps and one-click app installs do not support [Kubernetes role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). Support is [being worked on](https://gitlab.com/groups/gitlab-org/-/epics/136), but in the interim RBAC must be disabled to utilize for these features.
![rbac](img/rbac.png)
> **Note**: Disabling RBAC means that any application running in the cluster, or user who can authenticate to the cluster, has full API access. This is a [security concern](https://docs.gitlab.com/ee/user/project/clusters/#security-implications), and may not be desirable.
......
......@@ -57,6 +57,10 @@ module QA
element :labels_block
end
view 'app/views/projects/merge_requests/_mr_title.html.haml' do
element :edit_button
end
def fast_forward_possible?
!has_text?('Fast-forward merge is not possible')
end
......@@ -165,6 +169,10 @@ module QA
all_elements(:discussion_reply).last.click
fill_element :reply_input, reply_text
end
def edit!
click_element :edit_button
end
end
end
end
......
......@@ -11,7 +11,9 @@ module QA
:target_branch,
:assignee,
:milestone,
:labels
:labels,
:file_name,
:file_content
attribute :project do
Project.fabricate! do |resource|
......@@ -35,8 +37,8 @@ module QA
resource.branch_name = target_branch
resource.remote_branch = source_branch
resource.new_branch = false
resource.file_name = "added_file.txt"
resource.file_content = "File Added"
resource.file_name = file_name
resource.file_content = file_content
end
end
......@@ -48,6 +50,8 @@ module QA
@assignee = nil
@milestone = nil
@labels = []
@file_name = "added_file.txt"
@file_content = "File Added"
end
def fabricate!
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment