root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-10-09 15:09:18 +00:00
parent 9cdba33385
commit 960d1d4c59
19 changed files with 67 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.rubocop_todo.yml
View File

@ -1170,9 +1170,6 @@ Rails/SaveBang:
- 'spec/support/shared_contexts/email_shared_context.rb'
- 'spec/support/shared_contexts/finders/group_projects_finder_shared_contexts.rb'
- 'spec/support/shared_contexts/mailers/notify_shared_context.rb'
- 'spec/tasks/gitlab/web_hook_rake_spec.rb'
- 'spec/uploaders/file_uploader_spec.rb'
- 'spec/uploaders/object_storage_spec.rb'
# Offense count: 187
# Cop supports --auto-correct.

5
changelogs/unreleased/mb_rails_save_bang_fix2.yml Normal file
View File

@ -0,0 +1,5 @@
---
title: Fix Rails/SaveBang offenses in spec/uploaders/* and spec/tasks/
merge_request: 44820
author: matthewbried
type: other

3
doc/api/group_clusters.md
View File

@ -8,8 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30213) in GitLab 12.1.
NOTE: **Note:**
User will need at least maintainer access for the group to use these endpoints.
Users need at least [Maintainer](../user/permissions.md) access for the group to use these endpoints.
## List group clusters

5
doc/api/members.md
View File

@ -227,7 +227,10 @@ Example response:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/217384) in GitLab 13.5.
Gets a list of group members who counts as billable, including members in the sub group/project.
Gets a list of group members that count as billable. The list includes members in the subgroup or subproject.
NOTE:
Unlike other API endpoints, billable members is updated once per day at 12:00 UTC.
This function takes [pagination](README.md#pagination) parameters `page` and `per_page` to restrict the list of users.

3
doc/api/project_clusters.md
View File

@ -8,8 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/23922) in GitLab 11.7.
NOTE: **Note:**
User will need at least maintainer access to use these endpoints.
Users need at least [Maintainer](../user/permissions.md) access to use these endpoints.
## List project clusters

4
doc/development/chatops_on_gitlabcom.md
View File

@ -22,9 +22,7 @@ To request access to Chatops on GitLab.com:
1. Log into <https://ops.gitlab.net/users/sign_in> **using the same username** as for GitLab.com (you may have to rename it).
1. You could also use the "Sign in with" Google button to sign in, with your GitLab.com email address.
1. Ask one of your team members to add you to the `chatops` project in Ops. They can do it by running `/chatops run member add <username> gitlab-com/chatops --ops` command in the `#chat-ops-test` Slack channel.
NOTE: **Note:**
If you had to change your username for GitLab.com on the first step, make sure [to reflect this information](https://gitlab.com/gitlab-com/www-gitlab-com#adding-yourself-to-the-team-page) on [the team page](https://about.gitlab.com/company/team/).
1. If you had to change your username for GitLab.com on the first step, make sure [to reflect this information](https://gitlab.com/gitlab-com/www-gitlab-com#adding-yourself-to-the-team-page) on [the team page](https://about.gitlab.com/company/team/).
## See also

7
doc/user/clusters/applications.md
View File

@ -11,7 +11,7 @@ applications which can be added directly to your configured cluster. These
applications are needed for [Review Apps](../../ci/review_apps/index.md) and
[deployments](../../ci/environments/index.md) when using [Auto DevOps](../../topics/autodevops/index.md).
You can install them after you [create a cluster](../project/clusters/add_remove_clusters.md). GitLab provides
GitLab Managed Apps that can installed with [one-click](#install-with-one-click) or [using CI/CD](#install-using-gitlab-cicd-alpha).
GitLab Managed Apps that can installed with [one-click](#install-with-one-click) or [using CI/CD](#install-using-gitlab-cicd-alpha).
## Install with one click
@ -143,7 +143,6 @@ The Ingress Controller installed is
[Ingress-NGINX](https://kubernetes.io/docs/concepts/services-networking/ingress/),
which is supported by the Kubernetes community.
NOTE: **Note:**
With the following procedure, a load balancer must be installed in your cluster
to obtain the endpoint. You can use either
Ingress, or Knative's own load balancer ([Istio](https://istio.io)) if using Knative.
@ -725,8 +724,8 @@ least 2 people from the
### Install Sentry using GitLab CI/CD
NOTE: **Note:**
The Sentry Helm chart [recommends](https://github.com/helm/charts/blob/f6e5784f265dd459c5a77430185d0302ed372665/stable/sentry/values.yaml#L284-L285) at least 3GB of available RAM for database migrations.
The Sentry Helm chart [recommends](https://github.com/helm/charts/blob/f6e5784f265dd459c5a77430185d0302ed372665/stable/sentry/values.yaml#L284-L285)
at least 3 GB of available RAM for database migrations.
To install Sentry, define the `.gitlab/managed-apps/config.yaml` file
with:

5
doc/user/clusters/environments.md
View File

@ -43,6 +43,5 @@ Once you have successful deployments to your group-level or instance-level clust
1. Navigate to your group's **Kubernetes** page.
1. Click on the **Environments** tab.
NOTE: **Note:**
Only successful deployments to the cluster is included in this page.
Non-cluster environments will not be included.
Only successful deployments to the cluster are included in this page.
Non-cluster environments aren't included.

3
doc/user/group/clusters/index.md
View File

@ -72,9 +72,8 @@ for deployments with a cluster not managed by GitLab, you must ensure:
(this is [not automatic](https://gitlab.com/gitlab-org/gitlab/-/issues/31519)). Editing
`KUBE_NAMESPACE` directly is discouraged.
NOTE: **Note:**
If you [install applications](#installing-applications) on your cluster, GitLab creates
the resources required to run them even if you choose to manage your own cluster.
the resources required to run them, even if you choose to manage your own cluster.
### Clearing the cluster cache

9
doc/user/infrastructure/index.md
View File

@ -67,8 +67,9 @@ local machine, this is a simple way to get started:
1. On your local machine, run `terraform init`, passing in the following options,
replacing `<YOUR-STATE-NAME>`, `<YOUR-PROJECT-ID>`, `<YOUR-USERNAME>` and
`<YOUR-ACCESS-TOKEN>` with the relevant values. This command initializes your
Terraform state, and stores that state within your GitLab project. This example
uses `gitlab.com`:
Terraform state, and stores that state within your GitLab project. The name of
your state can contain only uppercase and lowercase letters, decimal digits,
hyphens, and underscores. This example uses `gitlab.com`:
```shell
terraform init \
@ -82,10 +83,6 @@ local machine, this is a simple way to get started:
-backend-config="retry_wait_min=5"
```
NOTE: **Note:**
The name of your state can contain only uppercase and lowercase letters,
decimal digits, hyphens and underscores.
You can now run `terraform plan` and `terraform apply` as you normally would.
## Get started using GitLab CI

8
doc/user/project/clusters/add_eks_clusters.md
View File

@ -65,7 +65,9 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
1. In the [IAM Management Console](https://console.aws.amazon.com/iam/home), create an IAM policy:
1. From the left panel, select **Policies**.
1. Click **Create Policy**, which opens a new window.
1. Select the **JSON** tab, and paste in the following snippet in place of the existing content:
1. Select the **JSON** tab, and paste the following snippet in place of the
existing content. These permissions give GitLab the ability to create
resources, but not delete them:
```json
{
@ -112,9 +114,7 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
}
```
NOTE: **Note:**
These permissions give GitLab the ability to create resources, but not delete them.
This means that if an error is encountered during the creation process, changes will
If an error is encountered during the creation process, changes will
not be rolled back and you must remove resources manually. You can do this by deleting
the relevant [CloudFormation stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-delete-stack.html)

17
doc/user/project/clusters/add_remove_clusters.md
View File

@ -44,6 +44,8 @@ Before [adding a Kubernetes cluster](#create-new-cluster) using GitLab, you need
## Access controls
> - Restricted service account for deployment was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/51716) in GitLab 11.5.
When creating a cluster in GitLab, you are asked if you would like to create either:
- A [Role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
@ -55,9 +57,6 @@ GitLab creates the necessary service accounts and privileges to install and run
a `gitlab` service account with `cluster-admin` privileges is created in the `default` namespace
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.
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 is used by Helm to
@ -152,11 +151,12 @@ Amazon Elastic Kubernetes Service (EKS) at the project, group, or instance level
## Add existing cluster
If you have an existing Kubernetes cluster, you can add it to a project, group, or instance.
If you have an existing Kubernetes cluster, you can add it to a project, group,
or instance.
NOTE: **Note:**
Kubernetes integration is not supported for arm64 clusters. See the issue
[Helm Tiller fails to install on arm64 cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/29838) for details.
Kubernetes integration isn't supported for arm64 clusters. See the issue
[Helm Tiller fails to install on arm64 cluster](https://gitlab.com/gitlab-org/gitlab/-/issues/29838)
for details.
### Existing Kubernetes cluster
@ -191,7 +191,6 @@ To add a Kubernetes cluster to your project, group, or instance:
kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
```
NOTE: **Note:**
If the command returns the entire certificate chain, you must copy the Root CA
certificate and any intermediate certificates at the bottom of the chain.
A chain file has following structure:
@ -321,7 +320,7 @@ integration to work properly.
![RBAC](img/rbac_v13_1.png)
NOTE: **Note:**
CAUTION: **Caution:**
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](index.md#security-implications), and may not be desirable.

4
doc/user/project/clusters/runbooks/index.md
View File

@ -115,9 +115,7 @@ the components outlined above and the pre-loaded demo runbook.
VARIABLE_VALUE = project.variables.get('PRIVATE_TOKEN').value
```
1. To configure the operation of a runbook, create and configure variables:
NOTE: **Note:**
1. To configure the operation of a runbook, create and configure variables.
For this example, we are using the **Run SQL queries in Notebook** section in the
sample runbook to query a PostgreSQL database. The first four lines of the following
code block define the variables that are required for this query to function:

8
doc/user/project/clusters/serverless/aws.md
View File

@ -136,8 +136,8 @@ This example code does the following:
In order to interact with your AWS account, the GitLab CI/CD pipelines require both `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be defined in your GitLab settings under **Settings > CI/CD > Variables**.
For more information please see [Create a custom variable in the UI](../../../../ci/variables/README.md#create-a-custom-variable-in-the-ui).
NOTE: **Note:**
The AWS credentials you provide must include IAM policies that provision correct access control to AWS Lambda, API Gateway, CloudFormation, and IAM resources.
The AWS credentials you provide must include IAM policies that provision correct
access control to AWS Lambda, API Gateway, CloudFormation, and IAM resources.
#### Deploying your function
@ -154,9 +154,7 @@ endpoints:
#### Manually testing your function
Running the following `curl` command should trigger your function.
NOTE: **Note:**
Your URL should be the one retrieved from the GitLab deploy stage log.
Your URL should be the one retrieved from the GitLab deploy stage log:
```shell
curl https://u768nzby1j.execute-api.us-east-1.amazonaws.com/production/hello

49
doc/user/project/clusters/serverless/index.md
View File

@ -75,8 +75,8 @@ To run Knative on GitLab, you will need:
## Installing Knative via GitLab's Kubernetes integration
NOTE: **Note:**
The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.50 GB memory. **RBAC must be enabled.**
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).
1. Select the **Applications** tab and scroll down to the Knative app section. Enter the domain to be used with
@ -99,22 +99,19 @@ The minimum recommended cluster size to run Knative is 3-nodes, 6 vCPUs, and 22.
![DNS entry](img/dns-entry.png)
NOTE: **Note:**
You can deploy either [functions](#deploying-functions) or [serverless applications](#deploying-serverless-applications)
on a given project but not both. The current implementation makes use of a `serverless.yml` file to signal a FaaS project.
on a given project, but not both. The current implementation makes use of a
`serverless.yml` file to signal a FaaS project.
## Using an existing installation of Knative
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58941) in GitLab 12.0.
NOTE: **Note:**
The "invocations" monitoring feature of GitLab serverless will not work when
The _invocations_ monitoring feature of GitLab serverless won't work when
adding an existing installation of Knative.
It is also possible to use GitLab Serverless with an existing Kubernetes
cluster which already has Knative installed.
You must do the following:
It's also possible to use GitLab Serverless with an existing Kubernetes cluster
which already has Knative installed. You must do the following:
1. Follow the steps to
[add an existing Kubernetes
@ -453,16 +450,16 @@ To run a function locally:
> Introduced in GitLab 11.5.
12345678901234567890123456789012345678901234567890123456789012345678901234567890
Serverless applications are an alternative to [serverless functions](#deploying-functions).
They are useful in scenarios where an existing runtime does not meet the needs of an application,
such as one written in a language that has no runtime available. Note though that serverless
applications should be stateless!
They're useful in scenarios where an existing runtime does not meet the needs of
an application, such as one written in a language that has no runtime available.
Note though that serverless applications should be stateless.
NOTE: **Note:**
You can reference and import the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get started.
Add the following `.gitlab-ci.yml` to the root of your repository
(you may skip this step if you've previously cloned the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) mentioned above):
You can reference and import the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app)
to get started. Add the following `.gitlab-ci.yml` to the root of your repository
(you may skip this step if you've previously cloned the previously mentioned,
sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app)):
```yaml
include:
@ -561,14 +558,18 @@ Or:
## Enabling TLS for Knative services
By default, a GitLab serverless deployment will be served over `http`. In order to serve over `https` you
must manually obtain and install TLS certificates.
By default, a GitLab serverless deployment will be served over `http`. To serve
over `https`, you must manually obtain and install TLS certificates.
The simplest way to accomplish this is to
use [Certbot to manually obtain Let's Encrypt certificates](https://knative.dev/docs/serving/using-a-tls-cert/#using-certbot-to-manually-obtain-let-s-encrypt-certificates). Certbot is a free, open source software tool for automatically using Let’s Encrypt certificates on manually-administrated websites to enable HTTPS.
12345678901234567890123456789012345678901234567890123456789012345678901234567890
The simplest way to accomplish this is to use Certbot to
[manually obtain Let's Encrypt certificates](https://knative.dev/docs/serving/using-a-tls-cert/#using-certbot-to-manually-obtain-let-s-encrypt-certificates).
Certbot is a free, open source software tool for automatically using Let’s Encrypt
certificates on manually-administrated websites to enable HTTPS.
NOTE: **Note:**
The instructions below relate to installing and running Certbot on a Linux server that has Python 3 installed and may not work on other operating systems or with other versions of Python.
The following instructions relate to installing and running Certbot on a Linux
server that has Python 3 installed, and may not work on other operating systems
or with other versions of Python.
1. Install Certbot by running the
[`certbot-auto` wrapper script](https://certbot.eff.org/docs/install.html#certbot-auto).

2
spec/controllers/projects/settings/operations_controller_spec.rb
View File

@ -504,7 +504,7 @@ RSpec.describe Projects::Settings::OperationsController do
it_behaves_like 'PATCHable'
describe 'gitlab tracking', :snowplow, quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/259282#note_425243784' do
describe 'gitlab tracking', :snowplow do
shared_examples 'event tracking' do
it 'tracks an event' do
expect_snowplow_event(

4
spec/tasks/gitlab/web_hook_rake_spec.rb
View File

@ -36,7 +36,7 @@ RSpec.describe 'gitlab:web_hook namespace rake tasks' do
it 'raises an error if an unknown namespace is specified' do
stub_env('URL' => url, 'NAMESPACE' => group.full_path)
group.destroy
group.destroy!
expect { run_rake_task('gitlab:web_hook:add') }.to raise_error(SystemExit)
end
@ -69,7 +69,7 @@ RSpec.describe 'gitlab:web_hook namespace rake tasks' do
it 'raises an error if an unknown namespace is specified' do
stub_env('URL' => url, 'NAMESPACE' => group.full_path)
group.destroy
group.destroy!
expect { run_rake_task('gitlab:web_hook:rm') }.to raise_error(SystemExit)
end

2
spec/uploaders/file_uploader_spec.rb
View File

@ -285,7 +285,7 @@ RSpec.describe FileUploader do
end
let!(:fog_file) do
fog_connection.directories.new(key: 'uploads').files.create(
fog_connection.directories.new(key: 'uploads').files.create( # rubocop:disable Rails/SaveBang
key: 'tmp/uploads/test/123123',
body: 'content'
)

2
spec/uploaders/object_storage_spec.rb
View File

@ -795,7 +795,7 @@ RSpec.describe ObjectStorage do
end
let!(:fog_file) do
fog_connection.directories.new(key: 'uploads').files.create(
fog_connection.directories.new(key: 'uploads').files.create( # rubocop:disable Rails/SaveBang
key: 'tmp/uploads/test/123123',
body: 'content'
)