Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
f155cc9034
commit
3546e1bb09
14 changed files with 114 additions and 41 deletions
|
|
@ -32,6 +32,7 @@ export default class LabelsSelect {
|
|||
$selectbox,
|
||||
$sidebarCollapsedValue,
|
||||
$value,
|
||||
$dropdownMenu,
|
||||
abilityName,
|
||||
defaultLabel,
|
||||
issueUpdateURL,
|
||||
|
|
@ -67,6 +68,7 @@ export default class LabelsSelect {
|
|||
$sidebarCollapsedValue = $block.find('.sidebar-collapsed-icon span');
|
||||
$sidebarLabelTooltip = $block.find('.js-sidebar-labels-tooltip');
|
||||
$value = $block.find('.value');
|
||||
$dropdownMenu = $dropdown.parent().find('.dropdown-menu');
|
||||
$loading = $block.find('.block-loading').fadeOut();
|
||||
fieldName = $dropdown.data('fieldName');
|
||||
initialSelected = $selectbox
|
||||
|
|
@ -454,9 +456,21 @@ export default class LabelsSelect {
|
|||
}
|
||||
|
||||
$loading.fadeIn();
|
||||
const oldLabels = boardsStore.detail.issue.labels;
|
||||
|
||||
boardsStore.detail.issue
|
||||
.update($dropdown.attr('data-issue-update'))
|
||||
.then(() => {
|
||||
if (isScopedLabel(label)) {
|
||||
const prevIds = oldLabels.map(label => label.id);
|
||||
const newIds = boardsStore.detail.issue.labels.map(label => label.id);
|
||||
const differentIds = _.difference(prevIds, newIds);
|
||||
$dropdown.data('marked', newIds);
|
||||
$dropdownMenu
|
||||
.find(differentIds.map(id => `[data-label-id="${id}"]`).join(','))
|
||||
.removeClass('is-active');
|
||||
}
|
||||
})
|
||||
.then(fadeOutLoader)
|
||||
.catch(fadeOutLoader);
|
||||
} else if (handleClick) {
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ Parameters:
|
|||
- `title` (required) - The title of a snippet
|
||||
- `file_name` (required) - The name of a snippet file
|
||||
- `description` (optional) - The description of a snippet
|
||||
- `code` (required) - The content of a snippet
|
||||
- `content` (required) - The content of a snippet
|
||||
- `visibility` (required) - The snippet's visibility
|
||||
|
||||
Example request:
|
||||
|
|
@ -97,7 +97,7 @@ curl --request POST https://gitlab.com/api/v4/projects/:id/snippets \
|
|||
"title" : "Example Snippet Title",
|
||||
"description" : "More verbose snippet description",
|
||||
"file_name" : "example.txt",
|
||||
"code" : "source code \n with multiple lines\n",
|
||||
"content" : "source code \n with multiple lines\n",
|
||||
"visibility" : "private"
|
||||
}
|
||||
```
|
||||
|
|
@ -117,7 +117,7 @@ Parameters:
|
|||
- `title` (optional) - The title of a snippet
|
||||
- `file_name` (optional) - The name of a snippet file
|
||||
- `description` (optional) - The description of a snippet
|
||||
- `code` (optional) - The content of a snippet
|
||||
- `content` (optional) - The content of a snippet
|
||||
- `visibility` (optional) - The snippet's visibility
|
||||
|
||||
Example request:
|
||||
|
|
@ -136,7 +136,7 @@ curl --request PUT https://gitlab.com/api/v4/projects/:id/snippets \
|
|||
"title" : "Updated Snippet Title",
|
||||
"description" : "More verbose snippet description",
|
||||
"file_name" : "new_filename.txt",
|
||||
"code" : "updated source code \n with multiple lines\n",
|
||||
"content" : "updated source code \n with multiple lines\n",
|
||||
"visibility" : "private"
|
||||
}
|
||||
```
|
||||
|
|
|
|||
|
|
@ -491,8 +491,8 @@ job B:
|
|||
To fix that, use different `keys` for each job.
|
||||
|
||||
In another case, let's assume you have more than one Runners assigned to your
|
||||
project, but the distributed cache is not enabled. We want the second time the
|
||||
pipeline is run, `job A` and `job B` to re-use their cache (which in this case
|
||||
project, but the distributed cache is not enabled. The second time the
|
||||
pipeline is run, we want `job A` and `job B` to re-use their cache (which in this case
|
||||
will be different):
|
||||
|
||||
```yaml
|
||||
|
|
@ -518,7 +518,7 @@ job B:
|
|||
```
|
||||
|
||||
In that case, even if the `key` is different (no fear of overwriting), you
|
||||
might experience the cached files to "get cleaned" before each stage if the
|
||||
might experience that the cached files "get cleaned" before each stage if the
|
||||
jobs run on different Runners in the subsequent pipelines.
|
||||
|
||||
## Clearing the cache
|
||||
|
|
|
|||
|
|
@ -151,13 +151,13 @@ parent project. This means you cannot completely trust the pipeline result,
|
|||
because, technically, external contributors can disguise their pipeline results
|
||||
by tweaking their GitLab Runner in the forked project.
|
||||
|
||||
There are multiple reasons about why GitLab doesn't allow those pipelines to be
|
||||
There are multiple reasons why GitLab doesn't allow those pipelines to be
|
||||
created in the parent project, but one of the biggest reasons is security concern.
|
||||
External users could steal secret variables from the parent project by modifying
|
||||
`.gitlab-ci.yml`, which could be some sort of credentials. This should not happen.
|
||||
|
||||
We're discussing a secure solution of running pipelines for merge requests
|
||||
that submitted from forked projects,
|
||||
that are submitted from forked projects,
|
||||
see [the issue about the permission extension](https://gitlab.com/gitlab-org/gitlab-foss/issues/23902).
|
||||
|
||||
## Additional predefined variables
|
||||
|
|
|
|||
|
|
@ -24,8 +24,8 @@ In the above example:
|
|||
|
||||
- A Review App is built every time a commit is pushed to `topic branch`.
|
||||
- The reviewer fails two reviews before passing the third review.
|
||||
- Once the review as passed, `topic branch` is merged into `master` where it's deploy to staging.
|
||||
- After been approved in staging, the changes that were merged into `master` are deployed in to production.
|
||||
- Once the review has passed, `topic branch` is merged into `master` where it is deployed to staging.
|
||||
- After having been approved in staging, the changes that were merged into `master` are deployed in to production.
|
||||
|
||||
## How Review Apps work
|
||||
|
||||
|
|
|
|||
|
|
@ -157,7 +157,7 @@ curl --request POST \
|
|||
You can also benefit by using triggers in your `.gitlab-ci.yml`. Let's say that
|
||||
you have two projects, A and B, and you want to trigger a rebuild on the `master`
|
||||
branch of project B whenever a tag on project A is created. This is the job you
|
||||
need to add in project's A `.gitlab-ci.yml`:
|
||||
need to add in project A's `.gitlab-ci.yml`:
|
||||
|
||||
```yaml
|
||||
build_docs:
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ To make full use of Auto DevOps, you will need:
|
|||
- **GitLab Runner** (for all stages)
|
||||
|
||||
Your Runner needs to be configured to be able to run Docker. Generally this
|
||||
means using the either the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
|
||||
means using either the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
|
||||
or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes.html) executors, with
|
||||
[privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
|
||||
|
||||
|
|
@ -1169,13 +1169,13 @@ This configuration is deprecated and will be removed in the future.
|
|||
TIP: **Tip:**
|
||||
You can also set this inside your [project's settings](#deployment-strategy).
|
||||
|
||||
This configuration based on
|
||||
This configuration is based on
|
||||
[incremental rollout to production](#incremental-rollout-to-production-premium).
|
||||
|
||||
Everything behaves the same way, except:
|
||||
|
||||
- It's enabled by setting the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`.
|
||||
- Instead of the standard `production` job, the following jobs with a 5 minute delay between each are created:
|
||||
- Instead of the standard `production` job, the following jobs are created with a 5 minute delay between each :
|
||||
1. `timed rollout 10%`
|
||||
1. `timed rollout 25%`
|
||||
1. `timed rollout 50%`
|
||||
|
|
|
|||
|
|
@ -54,6 +54,9 @@ To change it at the:
|
|||
1. Change the value of **maximum artifacts size (in MB)**.
|
||||
1. Press **Save changes** for the changes to take effect.
|
||||
|
||||
NOTE: **Note**
|
||||
The setting at all levels is only available to GitLab administrators.
|
||||
|
||||
## Default artifacts expiration **(CORE ONLY)**
|
||||
|
||||
The default expiration time of the [job artifacts](../../../administration/job_artifacts.md)
|
||||
|
|
|
|||
|
|
@ -2,9 +2,9 @@
|
|||
|
||||
## Overview
|
||||
|
||||
Labels allow you to categorize issues or merge requests using descriptive titles like
|
||||
Labels allow you to categorize epics, issues, and merge requests using descriptive titles like
|
||||
`bug`, `feature request`, or `docs`. Each label also has a customizable color. They
|
||||
allow you to quickly and dynamically filter and manage issues or merge requests you
|
||||
allow you to quickly and dynamically filter and manage epics, issues and merge requests you
|
||||
care about, and are visible throughout GitLab in most places where issues and merge
|
||||
requests are located.
|
||||
|
||||
|
|
@ -12,8 +12,8 @@ requests are located.
|
|||
|
||||
In GitLab, you can create project and group labels:
|
||||
|
||||
- **Project labels** can be assigned to issues or merge requests in that project only.
|
||||
- **Group labels** can be assigned to any issue or merge request in any project in
|
||||
- **Project labels** can be assigned to epics, issues and merge requests in that project only.
|
||||
- **Group labels** can be assigned to any epics, issue and merge request in any project in
|
||||
that group, or any subgroups of the group.
|
||||
|
||||
## Scoped labels **(PREMIUM)**
|
||||
|
|
@ -21,7 +21,7 @@ In GitLab, you can create project and group labels:
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9175) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.10.
|
||||
|
||||
Scoped labels allow teams to use the simple and familiar label feature to
|
||||
annotate their issues, merge requests, and epics to achieve custom fields and
|
||||
annotate their epics, issues, merge requests, and epics to achieve custom fields and
|
||||
custom workflow states by leveraging a special label title syntax.
|
||||
|
||||
A scoped label is a kind of label defined by a special double-colon syntax
|
||||
|
|
@ -141,11 +141,8 @@ action cannot be reversed and the changes are permanent.
|
|||
|
||||
## Assigning labels from the sidebar
|
||||
|
||||
Every issue and merge request can be assigned any number of labels. The labels are
|
||||
visible on every issue and merge request page, in the sidebar. They are also visible on:
|
||||
|
||||
- Every issue and merge request page in the sidebar.
|
||||
- The issue board.
|
||||
Every epic, issue, and merge request can be assigned any number of labels. The labels are
|
||||
visible on every epic, issue and merge request page, in the sidebar and on your issue boards.
|
||||
|
||||
From the sidebar, you can assign or unassign a label to the object (i.e. label or
|
||||
unlabel it). You can also perform this as a [quick action](quick_actions.md),
|
||||
|
|
@ -166,11 +163,11 @@ GitLab will check both the label titles and descriptions for the search.
|
|||
|
||||
## Filtering by label
|
||||
|
||||
The following can be filtered labels:
|
||||
The following can be filtered by labels:
|
||||
|
||||
- Epic lists **(ULTIMATE)**
|
||||
- Issue lists
|
||||
- Merge Request lists
|
||||
- Epic lists **(ULTIMATE)**
|
||||
- Issue Boards
|
||||
|
||||
### Filtering in list pages
|
||||
|
|
@ -180,7 +177,7 @@ The following can be filtered labels:
|
|||
- Group labels (including subgroup ancestors)
|
||||
- Project labels
|
||||
|
||||
- From the group issue list page and the group merge request list page, you can
|
||||
- From the group epic lists page, issue list page and the group merge request list page, you can
|
||||
[filter](../search/index.md#issues-and-merge-requests) by:
|
||||
- Group labels (including subgroup ancestors and subgroup descendants)
|
||||
- Project labels
|
||||
|
|
@ -214,7 +211,7 @@ The following can be filtered labels:
|
|||
|
||||
From the project label list page and the group label list page, you can subscribe
|
||||
to [notifications](../../workflow/notifications.md) of a given label, to alert you
|
||||
that the label has been assigned to an issue or merge request.
|
||||
that the label has been assigned to an epic, issue, and merge request.
|
||||
|
||||
|
||||
|
||||
|
|
@ -226,7 +223,7 @@ that the label has been assigned to an issue or merge request.
|
|||
> - Priority sorting is based on the highest priority label only. [This discussion](https://gitlab.com/gitlab-org/gitlab-foss/issues/18554) considers changing this.
|
||||
|
||||
Labels can have relative priorities, which are used in the "Label priority" and
|
||||
"Priority" sort orders of the issue and merge request list pages.
|
||||
"Priority" sort orders of the epic, issue, and merge request list pages.
|
||||
|
||||
From the project label list page, star a label to indicate that it has a priority.
|
||||
|
||||
|
|
@ -242,8 +239,8 @@ on the project label list page.
|
|||
|
||||
|
||||
|
||||
On the merge request and issue pages, for both groups and projects, you can sort by `Label priority`
|
||||
and `Priority`, which account for objects (issues and merge requests) that have prioritized
|
||||
On the epic, merge request and issue pages, for both groups and projects, you can sort by `Label priority`
|
||||
and `Priority`, which account for objects (epic, issues, and merge requests) that have prioritized
|
||||
labels assigned to them.
|
||||
|
||||
If you sort by `Label priority`, GitLab considers this sort comparison order:
|
||||
|
|
|
|||
|
|
@ -50,14 +50,9 @@ For more examples on artifacts, follow the [artifacts reference in
|
|||
|
||||
## Browsing artifacts
|
||||
|
||||
> With GitLab 9.2, PDFs, images, videos and other formats can be previewed
|
||||
> directly in the job artifacts browser without the need to download them.
|
||||
> With [GitLab 10.1][ce-14399], HTML files in a public project can be previewed
|
||||
> directly in a new tab without the need to download them when
|
||||
> [GitLab Pages](../../../administration/pages/index.md) is enabled.
|
||||
> The same holds for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
|
||||
> With [GitLab 12.4][gitlab-16675], also artifacts in private projects can be previewed
|
||||
> when [GitLab Pages access control](../../../administration/pages/index.md#access-control) is enabled.
|
||||
> - From GitLab 9.2, PDFs, images, videos and other formats can be previewed directly in the job artifacts browser without the need to download them.
|
||||
> - Introduced in [GitLab 10.1][ce-14399], HTML files in a public project can be previewed directly in a new tab without the need to download them when [GitLab Pages](../../../administration/pages/index.md) is enabled. The same applies for textual formats (currently supported extensions: `.txt`, `.json`, and `.log`).
|
||||
> - Introduced in [GitLab 12.4][gitlab-16675], artifacts in private projects can be previewed when [GitLab Pages access control](../../../administration/pages/index.md#access-control) is enabled.
|
||||
|
||||
After a job finishes, if you visit the job's specific page, there are three
|
||||
buttons. You can download the artifacts archive or browse its contents, whereas
|
||||
|
|
@ -70,7 +65,7 @@ The archive browser shows the name and the actual file size of each file in the
|
|||
archive. If your artifacts contained directories, then you are also able to
|
||||
browse inside them.
|
||||
|
||||
Below you can see how browsing looks like. In this case we have browsed inside
|
||||
Below you can see what browsing looks like. In this case we have browsed inside
|
||||
the archive and at this point there is one directory, a couple files, and
|
||||
one HTML file that you can view directly online when
|
||||
[GitLab Pages](../../../administration/pages/index.md) is enabled (opens in a new tab).
|
||||
|
|
|
|||
|
|
@ -63,6 +63,19 @@ module Gitlab
|
|||
def self.monotonic_time
|
||||
Process.clock_gettime(Process::CLOCK_MONOTONIC, :float_second)
|
||||
end
|
||||
|
||||
def self.thread_cpu_time
|
||||
return unless defined?(Process::CLOCK_THREAD_CPUTIME_ID)
|
||||
|
||||
Process.clock_gettime(Process::CLOCK_THREAD_CPUTIME_ID, :float_second)
|
||||
end
|
||||
|
||||
def self.thread_cpu_duration(start_time)
|
||||
end_time = thread_cpu_time
|
||||
return unless start_time && end_time
|
||||
|
||||
end_time - start_time
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -44,6 +44,10 @@ module Gitlab
|
|||
duration.in_milliseconds.to_i
|
||||
end
|
||||
|
||||
def thread_cpu_duration
|
||||
System.thread_cpu_duration(@thread_cputime_start)
|
||||
end
|
||||
|
||||
def allocated_memory
|
||||
@memory_after - @memory_before
|
||||
end
|
||||
|
|
@ -53,12 +57,14 @@ module Gitlab
|
|||
|
||||
@memory_before = System.memory_usage
|
||||
@started_at = System.monotonic_time
|
||||
@thread_cputime_start = System.thread_cpu_time
|
||||
|
||||
yield
|
||||
ensure
|
||||
@memory_after = System.memory_usage
|
||||
@finished_at = System.monotonic_time
|
||||
|
||||
self.class.gitlab_transaction_cputime_seconds.observe(labels, thread_cpu_duration)
|
||||
self.class.gitlab_transaction_duration_seconds.observe(labels, duration)
|
||||
self.class.gitlab_transaction_allocated_memory_bytes.observe(labels, allocated_memory * 1024.0)
|
||||
|
||||
|
|
@ -142,6 +148,12 @@ module Gitlab
|
|||
"#{labels[:controller]}##{labels[:action]}" if labels && !labels.empty?
|
||||
end
|
||||
|
||||
define_histogram :gitlab_transaction_cputime_seconds do
|
||||
docstring 'Transaction thread cputime'
|
||||
base_labels BASE_LABELS
|
||||
buckets [0.1, 0.25, 0.5, 1.0, 2.5, 5.0]
|
||||
end
|
||||
|
||||
define_histogram :gitlab_transaction_duration_seconds do
|
||||
docstring 'Transaction duration'
|
||||
base_labels BASE_LABELS
|
||||
|
|
|
|||
|
|
@ -14,6 +14,8 @@ describe 'Issue Boards', :js do
|
|||
let!(:bug) { create(:label, project: project, name: 'Bug') }
|
||||
let!(:regression) { create(:label, project: project, name: 'Regression') }
|
||||
let!(:stretch) { create(:label, project: project, name: 'Stretch') }
|
||||
let!(:scoped_label_1) { create(:label, project: project, name: 'Scoped::Label1') }
|
||||
let!(:scoped_label_2) { create(:label, project: project, name: 'Scoped::Label2') }
|
||||
let!(:issue1) { create(:labeled_issue, project: project, assignees: [user], milestone: milestone, labels: [development], relative_position: 2) }
|
||||
let!(:issue2) { create(:labeled_issue, project: project, labels: [development, stretch], relative_position: 1) }
|
||||
let(:board) { create(:board, project: project) }
|
||||
|
|
@ -27,6 +29,8 @@ describe 'Issue Boards', :js do
|
|||
end
|
||||
|
||||
before do
|
||||
stub_licensed_features(scoped_labels: true)
|
||||
|
||||
project.add_maintainer(user)
|
||||
|
||||
sign_in(user)
|
||||
|
|
@ -309,6 +313,33 @@ describe 'Issue Boards', :js do
|
|||
expect(card).to have_content(bug.title)
|
||||
end
|
||||
|
||||
it 'removes existing scoped label' do
|
||||
click_card(card)
|
||||
|
||||
page.within('.labels') do
|
||||
click_link 'Edit'
|
||||
|
||||
wait_for_requests
|
||||
|
||||
click_link scoped_label_1.title
|
||||
click_link scoped_label_2.title
|
||||
|
||||
wait_for_requests
|
||||
|
||||
find('.dropdown-menu-close-icon').click
|
||||
|
||||
page.within('.value') do
|
||||
expect(page).to have_selector('.scoped-label-wrapper', count: 1)
|
||||
expect(page).not_to have_content(scoped_label_1.title)
|
||||
expect(page).to have_content(scoped_label_2.title)
|
||||
end
|
||||
end
|
||||
|
||||
expect(card).to have_selector('.scoped-label-wrapper', count: 1)
|
||||
expect(card).not_to have_content(scoped_label_1.title)
|
||||
expect(card).to have_content(scoped_label_2.title)
|
||||
end
|
||||
|
||||
it 'adds a multiple labels' do
|
||||
click_card(card)
|
||||
|
||||
|
|
|
|||
|
|
@ -27,6 +27,14 @@ describe Gitlab::Metrics::Transaction do
|
|||
end
|
||||
end
|
||||
|
||||
describe '#thread_cpu_duration' do
|
||||
it 'returns the duration of a transaction in seconds' do
|
||||
transaction.run { }
|
||||
|
||||
expect(transaction.thread_cpu_duration).to be > 0
|
||||
end
|
||||
end
|
||||
|
||||
describe '#allocated_memory' do
|
||||
it 'returns the allocated memory in bytes' do
|
||||
transaction.run { 'a' * 32 }
|
||||
|
|
|
|||
Loading…
Reference in a new issue