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 2021-11-19 06:10:06 +00:00
parent 1947c080b3
commit 97c07a2d3a
9 changed files with 2652 additions and 2408 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

58
.gitlab/issue_templates/UX Issue.md Normal file
View file

@ -0,0 +1,58 @@
<!-- This issue template can be used as a starting point for a UX Issue. This is not a feature request, rather an issue that is being created for a product designer to solve a problem.
The goal of this template is to ensure we have captured all the information available to the product designer so they can approach the problem creatively and efficiently. Please add links to SSOT if this informatin exists elsewhere. -->
### Who will use this solution?
<!-- If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)
* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
* [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)
-->
### What problem do they have?
### When do they have the problem?
### Where in the app do they have the problem and at what frequency (if known)?
### Why will a design help them?
### What is the JTBD and/or Tasks?
### Is this problem supported by user research (please link relevant research issue/s)?
### Known technical constraints
### How does this help the business?
/label ~"group::" ~"section::" ~"Category::" ~UX

2
GITALY_SERVER_VERSION
View file

@ -1 +1 @@
37118baf7b10c95f533230797d849d2251805236
b6dda5d1f7a7e05c34ed0f72f161a46aee536d75

57
doc/ci/environments/index.md
View file

@ -447,6 +447,63 @@ try to check out the code after the branch is deleted.
Read more in the [`.gitlab-ci.yml` reference](../yaml/index.md#environmenton_stop).
#### Stop an environment when another job is finished
You can set an environment to stop when another job is finished.
In your `.gitlab-ci.yml` file, specify in the [`on_stop:`](../yaml/index.md#environmenton_stop)
keyword the name of the job that stops the environment.
The following example shows a `review_app` job that calls a `stop_review_app` job after the first
job is finished. The `stop_review_app` is triggered based on what is defined under `when`. In this
case, it is set to `manual`, so it needs a
[manual action](../jobs/job_control.md#create-a-job-that-must-be-run-manually)
from the GitLab UI to run.
Both jobs must have the same rules or only/except configuration.
In this example, if the configuration is not identical:
- The `stop_review_app` job might not be included in all pipelines that include the `review_app` job.
- It is not possible to trigger the `action: stop` to stop the environment automatically.
Also in the example, `GIT_STRATEGY` is set to `none`. If the
`stop_review_app` job is [automatically triggered](../environments/index.md#stop-an-environment),
the runner won't try to check out the code after the branch is deleted.
The example also overwrites global variables. If your `stop` `environment` job depends
on global variables, use [anchor variables](../yaml/yaml_optimization.md#yaml-anchors-for-variables) when you set the `GIT_STRATEGY`
to change the job without overriding the global variables.
The `stop_review_app` job **must** have the following keywords defined:
- `when`, defined at either:
- [The job level](../yaml/index.md#when).
- [In a rules clause](../yaml/index.md#rules). If you use `rules:` and `when: manual`, you should
also set [`allow_failure: true`](../yaml/index.md#allow_failure) so the pipeline can complete
even if the job doesn't run.
- `environment:name`
- `environment:action`
```yaml
review_app:
stage: deploy
script: make deploy-app
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_ENVIRONMENT_SLUG.example.com
on_stop: stop_review_app
stop_review_app:
stage: deploy
variables:
GIT_STRATEGY: none
script: make delete-app
when: manual
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop
```
#### Stop an environment after a certain time period
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/20956) in GitLab 12.8.

4777
doc/ci/yaml/index.md
View file

File diff suppressed because it is too large Load diff

114
doc/development/work_items_widgets.md Normal file
View file

@ -0,0 +1,114 @@
---
stage: Plan
group: Project Management
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Work items widgets
## Frontend architecture
Widgets for work items are heavily inspired by [Frontend widgets](fe_guide/widgets.md).
You can expect some differences, because work items are architecturally different from issuables.
GraphQL (Vue Apollo) constitutes the core of work items widgets' stack.
### Retrieve widget information for work items
To display a work item page, the frontend must know which widgets are available
on the work item it is attempting to display. To do so, it needs to fetch the
list of widgets, using a query like this:
```plaintext
query WorkItem($workItemId: ID!) {
workItem(workItemId: $id) @client {
id
type
widgets {
nodes {
type
}
}
}
}
```
### GraphQL queries and mutations
GraphQL queries and mutations are work item agnostic. Work item queries and mutations
should happen at the widget level, so widgets are standalone reusable components.
The work item query and mutation should support any work item type and be dynamic.
They should allow you to query and mutate any work item attribute by specifying a widget identifier.
In this query example, the description widget uses the query and mutation to
display and update the description of any work item:
```plaintext
query {
workItem(input: {
workItemId: "gid://gitlab/AnyWorkItem/2207",
widgetIdentifier: "description",
}) {
id
type
widgets {
nodes {
... on DescriptionWidget {
contentText
}
}
}
}
}
```
Mutation example:
```plaintext
mutation {
updateWorkItem(input: {
workItemId: "gid://gitlab/AnyWorkItem/2207",
widgetIdentifier: "description",
value: "the updated description"
}) {
workItem {
id
description
}
}
}
```
### Widget's responsibility and structure
A widget is responsible for displaying and updating a single attribute, such as
title, description, or labels. Widgets must support any type of work item.
To maximize component reusability, widgets should be field wrappers owning the
work item query and mutation of the attribute it's responsible for.
A field component is a generic and simple component. It has no knowledge of the
attribute or work item details, such as input field, date selector, or dropdown.
Widgets must be configurable to support various use cases, depending on work items.
When building widgets, use slots to provide extra context while minimizing
the use of props and injected attributes.
### Examples
We have a [dropdown field component](https://gitlab.com/gitlab-org/gitlab/-/blob/eea9ad536fa2d28ee6c09ed7d9207f803142eed7/app/assets/javascripts/vue_shared/components/dropdown/dropdown_widget/dropdown_widget.vue)
for use as reference.
Any work item widget can wrap the dropdown component. The widget has knowledge of
the attribute it mutates, and owns the mutation for it. Multiple widgets can use
the same field component. For example:
- Title and description widgets use the input field component.
- Start and end date use the date selector component.
- Labels, milestones, and assignees selectors use the dropdown component.
Some frontend widgets already use the dropdown component. Use them as a reference
for work items widgets development:
- `ee/app/assets/javascripts/boards/components/assignee_select.vue`
- `ee/app/assets/javascripts/boards/components/milestone_select.vue`

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

@ -563,6 +563,8 @@ You should consider these security implications before configuring IP address re
requests a new job or an update to a job's state, it is also not bound by
the IP restrictions. But when the running CI/CD job sends Git requests from a
restricted IP address, the IP restriction prevents code from being cloned.
- **User dashboard activity**: Users may still see some events from the IP restricted groups and projects
on their dashboard. Activity may include push, merge, issue, or comment events.
To restrict group access by IP address:

21
qa/qa/page/admin/settings/component/usage_statistics.rb Normal file
View file

@ -0,0 +1,21 @@
# frozen_string_literal: true
module QA
module Page
module Admin
module Settings
module Component
class UsageStatistics < Page::Base
view 'app/views/admin/application_settings/_usage.html.haml' do
element :enable_usage_data_checkbox
end
def has_disabled_usage_data_checkbox?
has_element?(:enable_usage_data_checkbox, disabled: true)
end
end
end
end
end
end
end

7
qa/qa/page/admin/settings/metrics_and_profiling.rb
View file

@ -9,6 +9,7 @@ module QA
view 'app/views/admin/application_settings/metrics_and_profiling.html.haml' do
element :performance_bar_settings_content
element :usage_statistics_settings_content
end
def expand_performance_bar(&block)
@ -16,6 +17,12 @@ module QA
Component::PerformanceBar.perform(&block)
end
end
def expand_usage_statistics(&block)
expand_content(:usage_statistics_settings_content) do
Component::UsageStatistics.perform(&block)
end
end
end
end
end

22
qa/qa/specs/features/browser_ui/non_devops/service_ping_default_enabled_spec.rb Normal file
View file

@ -0,0 +1,22 @@
# frozen_string_literal: true
module QA
RSpec.describe 'Service ping default enabled' do
context 'When using default enabled from gitlab.yml config', :requires_admin do
before do
Flow::Login.sign_in_as_admin
Page::Main::Menu.perform(&:go_to_admin_area)
Page::Admin::Menu.perform(&:go_to_metrics_and_profiling_settings)
end
it 'has service ping toggle enabled' do
Page::Admin::Settings::MetricsAndProfiling.perform do |setting|
setting.expand_usage_statistics do |page|
expect(page).not_to have_disabled_usage_data_checkbox
end
end
end
end
end
end