Commit edc2a573 authored by GitLab Bot's avatar GitLab Bot
Browse files

Add latest changes from gitlab-org/gitlab@master

parent e987347fc408
......@@ -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.
![Labels subscriptions](img/labels_subscriptions_v12_1.png)
......@@ -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.
![Drag to change label priority](img/labels_drag_priority_v12_1.gif)
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 @@ def self.real_time(precision = :float_second)
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 @@ def duration_milliseconds
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 @@ def run
@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 @@ def action
"#{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 @@
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 @@
end
before do
stub_licensed_features(scoped_labels: true)
project.add_maintainer(user)
sign_in(user)
......@@ -309,6 +313,33 @@
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 @@
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 }
......
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