kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2020-11-09 18:09:11 +00:00
parent 22d08de610
commit 42c8bf6367
12 changed files with 146 additions and 63 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
.gitlab/ci/reports.gitlab-ci.yml
View file

@ -152,6 +152,26 @@ dependency_scanning:
dependency_scanning: gl-dependency-scanning-report.json
expire_in: 1 week # GitLab-specific
# The job below analysis dependencies for malicous behavior
package_hunter:
extends:
- .reports:schedule-dast
stage: test
image:
name: registry.gitlab.com/gitlab-com/gl-security/security-research/package-hunter-cli:latest
entrypoint: [""]
needs: []
script:
- rm -r spec locale .git app/assets/images doc/
- cd .. && tar -I "gzip --best" -cf gitlab.tgz gitlab/
- DEBUG=* HTR_user=$PACKAGE_HUNTER_USER HTR_pass=$PACKAGE_HUNTER_PASS node /usr/src/app/cli.js analyze --format gitlab gitlab.tgz | tee $CI_PROJECT_DIR/gl-dependency-scanning-report.json
artifacts:
paths:
- gl-dependency-scanning-report.json # GitLab-specific
reports:
dependency_scanning: gl-dependency-scanning-report.json
expire_in: 1 week # GitLab-specific
license_scanning:
extends:
- .default-retry

2
Gemfile
View file

@ -19,7 +19,7 @@ gem 'default_value_for', '~> 3.3.0'
gem 'pg', '~> 1.1'
gem 'rugged', '~> 0.28'
gem 'grape-path-helpers', '~> 1.4'
gem 'grape-path-helpers', '~> 1.5'
gem 'faraday', '~> 1.0'
gem 'marginalia', '~> 1.9.0'

6
Gemfile.lock
View file

@ -500,10 +500,10 @@ GEM
grape-entity (0.7.1)
activesupport (>= 4.0)
multi_json (>= 1.3.2)
grape-path-helpers (1.4.0)
grape-path-helpers (1.5.0)
activesupport
grape (~> 1.3)
rake (~> 12)
rake (> 12)
grape_logging (1.8.3)
grape
rack
@ -1365,7 +1365,7 @@ DEPENDENCIES
gpgme (~> 2.0.19)
grape (= 1.4.0)
grape-entity (~> 0.7.1)
grape-path-helpers (~> 1.4)
grape-path-helpers (~> 1.5)
grape_logging (~> 1.7)
graphiql-rails (~> 1.4.10)
graphlient (~> 0.4.0)

7
app/assets/javascripts/ide/components/mr_file_icon.vue
View file

@ -1,20 +1,19 @@
<script>
import { GlIcon } from '@gitlab/ui';
import tooltip from '~/vue_shared/directives/tooltip';
import { GlIcon, GlTooltipDirective } from '@gitlab/ui';
export default {
components: {
GlIcon,
},
directives: {
tooltip,
GlTooltip: GlTooltipDirective,
},
};
</script>
<template>
<gl-icon
v-tooltip
v-gl-tooltip
:title="__('Part of merge request changes')"
:size="12"
name="git-merge"

5
changelogs/unreleased/okr-tooltip-merge-button-sidebar-ide.yml Normal file
View file

@ -0,0 +1,5 @@
---
title: Migrate tooltip in app/assets/javascripts/vue_merge_request_widget/components/mr_file_icon.vue
merge_request: 46156
author: 46156
type: other

8
doc/api/releases/index.md
View file

@ -228,7 +228,7 @@ GET /projects/:id/releases/:tag_name
| Attribute | Type | Required | Description |
| ------------- | -------------- | -------- | ----------------------------------------------------------------------------------- |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
| `tag_name` | string | yes | The tag where the release will be created from. |
| `tag_name` | string | yes | The Git tag the release is associated with. |
Example request:
@ -508,7 +508,7 @@ POST /projects/:id/releases/:tag_name/evidence
| Attribute | Type | Required | Description |
| ------------- | -------------- | -------- | ----------------------------------------------------------------------------------- |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
| `tag_name` | string | yes | The tag where the release will be created from. |
| `tag_name` | string | yes | The Git tag the release is associated with. |
Example request:
@ -533,7 +533,7 @@ PUT /projects/:id/releases/:tag_name
| Attribute | Type | Required | Description |
| ------------- | --------------- | -------- | ----------------------------------------------------------------------------------------------------------- |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
| `tag_name` | string | yes | The tag where the release will be created from. |
| `tag_name` | string | yes | The Git tag the release is associated with. |
| `name` | string | no | The release name. |
| `description` | string | no | The description of the release. You can use [Markdown](../../user/markdown.md). |
| `milestones` | array of string | no | The title of each milestone to associate with the release. [GitLab Premium](https://about.gitlab.com/pricing/) customers can specify group milestones. To remove all milestones from the release, specify `[]`. |
@ -640,7 +640,7 @@ DELETE /projects/:id/releases/:tag_name
| Attribute | Type | Required | Description |
| ------------- | -------------- | -------- | ----------------------------------------------------------------------------------- |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](../README.md#namespaced-path-encoding). |
| `tag_name` | string | yes | The tag where the release will be created from. |
| `tag_name` | string | yes | The Git tag the release is associated with. |
Example request:

50
doc/ci/yaml/README.md
View file

@ -1408,37 +1408,20 @@ Other commonly used variables for `if` clauses:
#### `rules:changes`
To determine if jobs should be added to a pipeline, `rules: changes` clauses check
the files changed by Git push events.
`rules:changes` determines whether or not to add jobs to a pipeline by checking for
changes to specific files.
`rules: changes` works exactly the same way as [`only: changes` and `except: changes`](#onlychangesexceptchanges),
accepting an array of paths.
It always returns true and adds jobs to the pipeline if there is no Git push event.
For example, jobs with `rules: changes` always run on scheduled and tag pipelines,
because they are not associated with a Git push event. Only certain pipelines have
a Git push event associated with them:
- All pipelines with a `$CI_PIPELINE_SOURCE` of `merge_request` or `external_merge_request`.
- Branch pipelines, which have the `$CI_COMMIT_BRANCH` variable present and a `$CI_PIPELINE_SOURCE` of `push`.
It's recommended to use it only with branch pipelines or merge request pipelines.
For example, it's common to use `rules: changes` with one of the following `if` clauses:
- `if: $CI_COMMIT_BRANCH`
- `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'`
For example:
accepting an array of paths. It's recommended to only use `rules: changes` with branch
pipelines or merge request pipelines. For example, it's common to use `rules: changes`
with merge request pipelines:
```yaml
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- changes:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
changes:
- Dockerfile
when: manual
allow_failure: true
@ -1446,14 +1429,29 @@ docker build:
In this example:
- [`workflow: rules`](#workflowrules) allows only pipelines for merge requests for all jobs.
- If the pipeline is a merge request pipeline, check `Dockerfile` for changes.
- If `Dockerfile` has changed, add the job to the pipeline as a manual job, and allow the pipeline
to continue running even if the job is not triggered (`allow_failure: true`).
- If `Dockerfile` has not changed, do not add job to any pipeline (same as `when: never`).
To implement a rule similar to [`except: changes`](#onlychangesexceptchanges),
To use `rules: changes` with branch pipelines instead of merge request pipelines,
change the `if:` clause in the example above to:
```yaml
rules:
- if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH
```
To implement a rule similar to [`except:changes`](#onlychangesexceptchanges),
use `when: never`.
CAUTION: **Caution:**
You can use `rules: changes` with other pipeline types, but it is not recommended
because `rules: changes` always evaluates to true when there is no Git `push` event.
Tag pipelines, scheduled pipelines, and so on do **not** have a Git `push` event
associated with them. A `rules: changes` job is **always** added to those pipeline
if there is no `if:` statement that limits the job to branch or merge request pipelines.
#### `rules:exists`
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24021) in GitLab 12.4.

15
doc/development/i18n/externalization.md
View file

@ -480,6 +480,21 @@ This makes use of [`Intl.DateTimeFormat`](https://developer.mozilla.org/en-US/do
## Best practices
### Minimize translation updates
Updates can result in the loss of the translations for this string. To minimize risks,
avoid changes to strings, unless they:
- Add value to the user.
- Include extra context for translators.
For example, we should avoid changes like this:
```diff
- _('Number of things: %{count}') % { count: 10 }
+ n_('Number of things: %d', 10)
```
### Keep translations dynamic
There are cases when it makes sense to keep translations together within an array or a hash.

48
doc/development/product_analytics/usage_ping.md
View file

@ -422,11 +422,11 @@ w
api.trackRedisHllUserEvent('my_already_defined_event_name'),
```
1. Track event using base module `Gitlab::UsageDataCounters::HLLRedisCounter.track_event(entity_id, event_name)`.
1. Track event using base module `Gitlab::UsageDataCounters::HLLRedisCounter.track_event(values, event_name)`.
Arguments:
- `entity_id`: value we count. For example: user_id, visitor_id.
- `values`: One value or array of values we count. For example: user_id, visitor_id, user_ids.
- `event_name`: event name.
1. Get event data using `Gitlab::UsageDataCounters::HLLRedisCounter.unique_events(event_names:, start_date:, end_date)`.
@ -681,6 +681,50 @@ with any of the other services that are running. That is not how node metrics ar
always runs as a process alongside other GitLab components on any given node. From Usage Ping's perspective none of the node data would therefore
appear to be associated to any of the services running, since they all appear to be running on different hosts. To alleviate this problem, the `node_exporter` in GCK was arbitrarily "assigned" to the `web` service, meaning only for this service `node_*` metrics will appear in Usage Ping.
## Aggregated metrics
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/45979) in GitLab 13.6.
> - It's [deployed behind a feature flag](../../user/feature_flags.md), disabled by default.
> - It's enabled on GitLab.com.
CAUTION: **Warning:**
This feature is intended solely for internal GitLab use.
In order to add data for aggregated metrics into Usage Ping payload you should add corresponding definition into [`aggregated_metrics.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/aggregated_metrics.yml) file. Each aggregate definition includes following parts:
- name: unique name under which aggregate metric will be added to Usage Ping payload
- operator: operator that defines how aggregated metric data will be counted. Available operators are:
- `ANY`: removes duplicates and counts all entries that triggered any of listed events
- events: list of events names (from [`known_events.yml`](#known-events-in-usage-data-payload)) to aggregate into metric. All events in this list must have the same `redis_slot` and `aggregation` attributes.
Example aggregated metric entry:
```yaml
- name: example_aggregated_metric
operator: ANY
events: ['i_search_total', 'i_search_advanced', 'i_search_paid']
```
Aggregated metrics will be added under `aggregated_metrics` key in both `counts_weekly` and `counts_monthly` top level keys in Usage Ping payload.
```ruby
{
:counts_monthly => {
:deployments => 1003,
:successful_deployments => 78,
:failed_deployments => 275,
:packages => 155,
:personal_snippets => 2106,
:project_snippets => 407,
:promoted_issues => 719,
:aggregated_metrics => {
:example_aggregated_metric => 7
},
:snippets => 2513
}
}
```
## Example Usage Ping payload
The following is example content of the Usage Ping payload.

44
doc/security/password_length_limits.md
View file

@ -14,11 +14,31 @@ By default, GitLab supports passwords with:
GitLab administrators can modify password lengths:
- Using configuration file.
- [From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab 12.6, using the GitLab UI.
- Using the GitLab UI. **[From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab 12.6 this is the only available option.**
- Using configuration file. **Up to GitLab 12.5**.
Changing the minimum or maximum length does not affect existing user passwords. Existing users are
not asked to reset their password to adhere to the new limits. The new limit restriction applies
only during new user sign-ups and when an existing user performs a password reset.
## Modify minimum password length using GitLab UI
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) in GitLab 12.6
The user password length is set to a minimum of 8 characters by default.
To change the minimum password length using GitLab UI:
1. Go to **Admin Area > Settings**, then select **Sign-up restrictions**.
![Minimum password length settings](../user/admin_area/img/minimum_password_length_settings_v12_6.png)
1. Input a **Minimum password length** value greater than or equal to 8, then select **Save changes**.
## Modify maximum password length using configuration file
From GitLab 12.6, the minimum password length set in this configuration file is ignored. Minimum password lengths must instead be modified via the [GitLab UI](#modify-minimum-password-length-using-gitlab-ui).
The user password length is set to a maximum of 128 characters by default.
To change that for installations from source:
@ -42,26 +62,6 @@ To change that for installations from source:
1. [Restart GitLab](../administration/restart_gitlab.md#installations-from-source)
for the changes to take effect.
NOTE: **Note:**
From GitLab 12.6, the minimum password length set in this configuration file will be ignored. Minimum password lengths will now have to be modified via the [GitLab UI](#modify-minimum-password-length-using-gitlab-ui) instead.
## Modify minimum password length using GitLab UI
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) in GitLab 12.6
The user password length is set to a minimum of 8 characters by default.
To change that using GitLab UI:
In **Admin Area > Settings** (`/admin/application_settings/general`), go to the section **Sign-up restrictions**.
[Minimum password length settings](../user/admin_area/img/minimum_password_length_settings_v12_6.png)
Set the **Minimum password length** to a value greater than or equal to 8 and hit **Save changes** to save the changes.
CAUTION: **Caution:**
Changing minimum or maximum limit does not affect existing user passwords in any manner. Existing users will not be asked to reset their password to adhere to the new limits.
The new limit restriction will only apply during new user sign-ups and when an existing user performs a password reset.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues

2
doc/user/infrastructure/index.md
View file

@ -62,6 +62,8 @@ To get started with a GitLab-managed Terraform State, there are two different op
- [Use a local machine](#get-started-using-local-development).
- [Use GitLab CI](#get-started-using-gitlab-ci).
Terraform States can be found by navigating to a Project's **{cloud-gear}** **Operations > Terraform** page.
## Permissions for using Terraform
In GitLab version 13.1, [Maintainer access](../permissions.md) was required to use a

2
spec/support/shared_examples/boards/multiple_issue_boards_shared_examples.rb
View file

@ -48,7 +48,7 @@ RSpec.shared_examples 'multiple issue boards' do
expect(page).to have_button('This is a new board')
end
it 'deletes board' do
it 'deletes board', quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/280554' do
in_boards_switcher_dropdown do
click_button 'Delete board'
end