Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
09d9f0d988
commit
ec8587780b
|
|
@ -0,0 +1,161 @@
|
|||
- title: Streamlined top navigation menu
|
||||
body: |
|
||||
GitLab 14.0 introduces an all-new, streamlined top navigation menu to help you get where you're going faster and with fewer clicks. This new, consolidated menu offers the combined functionality of the previous Projects, Groups, and More menus. It gives you access to your projects, groups, and instance-level features with a single click. Additionally, all-new responsive views improve the navigation experience on smaller screens.
|
||||
stage: Create
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Free, Premium, Ultimate]
|
||||
url: https://gitlab.com/gitlab-org/gitlab/-/issues/332635
|
||||
image_url: https://about.gitlab.com/images/14_0/consolidated-top-nav.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Sidebar navigation redesign
|
||||
body: |
|
||||
GitLab is big. And it's getting bigger. As we've introduced new features and categories, navigating the densely-packed left sidebar has become less intuitive.
|
||||
|
||||
In GitLab 14.0 we've redesigned and restructured the left sidebar for improved usability, consistency, and discoverability. We've moved some links to features around, split up features in the **Operations** menu into three distinct menus, improved visual contrast, and optimized spacing so all the menu items can fit comfortably on a smaller screen. These changes are intended to better match your mental model of the DevOps lifecycle, and provide a more predictable and consistent experience while navigating within your projects and groups.
|
||||
stage: Create
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Free, Premium, Ultimate]
|
||||
url: https://gitlab.com/gitlab-org/gitlab/-/issues/332635
|
||||
image_url: https://about.gitlab.com/images/14_0/redesigned-left-sidebar.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Merge request reviews in VS Code
|
||||
body: |
|
||||
As a developer, you often spend a majority of your time working in your local development environment. When you're assigned a merge request for review, this requires you to leave your editor and perform that review inside of GitLab. While performing your review inside GitLab, you might also need to use your local editor to gain more context on the proposed changes.
|
||||
|
||||
[GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) version `3.21.0` for Visual Studio Code (VS Code) now supports the complete merge request review process, including threads. Select the GitLab icon in VS Code to open the [sidebar](https://gitlab.com/gitlab-org/gitlab-vscode-extension#sidebar-details) to display **Merge requests I'm reviewing**. Select a merge request overview to view the complete details and discussions of the merge request.
|
||||
|
||||
The sidebar also contains a list of all the changed files in the merge request. Selecting files opens a diff comparison for you to review the changes in VS Code. While viewing the diff, you can read feedback left on the files, and create new comments by selecting a line number and creating your comment. All comments and feedback you provide in VS Code are available in the GitLab web interface, making it easy for you to perform your reviews in VS Code, and other users to participate in GitLab.
|
||||
|
||||
We're really excited about bringing the complete merge request review process to you inside of VS Code. Let us know what you think by [opening an issue](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/new?issue%5Bmilestone_id%5D=) for GitLab Workflow.
|
||||
stage: Create
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Free, Premium, Ultimate]
|
||||
url: https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/README.md
|
||||
image_url: https://img.youtube.com/vi/F5ypjlOZ4-0/hqdefault.jpg
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Track usage of Code Owners
|
||||
body: |
|
||||
Code Owners are an important piece of the code review process in GitLab. When code owners are clearly identified, contributors can see who should review contributions to a file or repository. The Code Owners feature can also be used to establish a merge request approval process. Now, you can track which teams across your organization are using the Code Owners feature in their development workflow.
|
||||
|
||||
If you would like to drive adoption of Code Owners, sort the DevOps Adoption table by the Code Owners column to find teams that haven't yet adopted the feature so you can easily identify which teams need help getting started. Alternatively, find teams that have successfully configured Code Owners and get tips and feedback. The DevOps Adoption table is available at [the group level](https://docs.gitlab.com/ee/user/group/devops_adoption/) and [the instance level](https://docs.gitlab.com/ee/user/admin_area/analytics/dev_ops_report.html#devops-adoption).
|
||||
stage: Manage
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Ultimate]
|
||||
url: https://docs.gitlab.com/ee/user/admin_area/analytics/dev_ops_report#devops-adoption
|
||||
image_url: https://about.gitlab.com/images/14_0/codeownersadoption.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Set pronouns on GitLab user profiles
|
||||
body: |
|
||||
Pronouns have been added to GitLab user profiles. The pronouns appear next to user names in the **Profile** tab. You can:
|
||||
|
||||
- Decide whether or not to add pronouns to your profile.
|
||||
- Self-identify and enter whatever pronouns you prefer, without selecting from a predefined list.
|
||||
|
||||
Besides being more inclusive, GitLab wants help people use the correct pronouns when replying to comments to respect people's identity.
|
||||
stage: Manage
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Free, Premium, Ultimate]
|
||||
url: https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns
|
||||
image_url: https://about.gitlab.com/images/14_0/pronouns.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Container Scanning Integration with Trivy
|
||||
body: |
|
||||
Container scanning in GitLab now uses the Trivy engine by default. This change provides customers with more timely vulnerability intelligence updates, more accurate results, and support for a larger number of operating systems. Users who run container scanning with default settings are switched seamlessly and automatically to the new engine in GitLab 14.0. Users who customize the variables in their container scanning job should review our [migration guide](https://docs.gitlab.com/ee/user/application_security/container_scanning/#change-scanners) and make any necessary updates.
|
||||
stage: Protect
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Ultimate]
|
||||
url: https://docs.gitlab.com/ee/user/application_security/container_scanning
|
||||
image_url: https://about.gitlab.com/images/14_0/trivy_scanning_engine.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Aggregate identical DAST vulnerabilities into a single vulnerability
|
||||
body: |
|
||||
In GitLab 13.12 and earlier, all DAST vulnerabilities found in a scan were listed individually for each URL the vulnerability was found on. This could create many vulnerabilities when the fix was a single file or configuration change. For example: an issue with a server header sent with every HTTP response would be reported on every page on the site, rather than reported as a single issue with multiple occurrences.
|
||||
|
||||
To reduce the overhead of managing vulnerabilities, GitLab combines identical vulnerabilities found on multiple pages into a single reported vulnerability in the DAST report. The vulnerability details include a list of all the URLs where the vulnerability was found, rather than individual vulnerabilities being created in the vulnerability list and dashboard for each page.
|
||||
|
||||
This new reporting functionality will not retroactively combine vulnerabilities found in previous scans. It only applies to scans performed in GitLab 14.0 and later.
|
||||
stage: Secure
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Ultimate]
|
||||
url: https://docs.gitlab.com/ee/user/application_security/dast/#reports
|
||||
image_url: https://about.gitlab.com/images/14_0/dast_aggregated_urls.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Epic Boards
|
||||
body: |
|
||||
Epic Boards align teams and organizations by communicating the status of epics continuously. Previous versions of GitLab required you to view and sort epics in a list to view the overall status. Keeping epics up to date meant making most changes through an epic's detail page. Epic Boards enable you to visualize and refine all of your epics in one place, using a customizable, drag-and-drop interface that is easy for any teammate to understand and collaborate.
|
||||
|
||||
Epic Boards are also a game-changer for managing and visualizing ideal epic workflows, such as authoring workflow states (Draft, Writing, Done), DevOps workflow states (such as Planned, In Development, and In Production), or any other mutually exclusive states you might model with scoped labels. Visualizing workflows with an Epic Board empowers you to increase predictability and efficiency.
|
||||
stage: Plan
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Premium, Ultimate]
|
||||
url: https://docs.gitlab.com/ee/user/group/epics/epic_boards.html
|
||||
image_url: https://about.gitlab.com/images/14_0/epic-boards.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Edit wiki pages with the WYSIWYG Markdown editor
|
||||
body: |
|
||||
Editing wiki content could be so much easier! Many GitLab wikis use Markdown formatting, and for some users, Markdown is a barrier to efficient collaboration. In this release, you now have access to a rich, modern Markdown editing experience in your wiki, so you can edit with confidence.
|
||||
|
||||
Instant feedback and visual editing tools help make wiki editing more intuitive, and remove barriers to collaboration. GitLab saves the changes as Markdown when you're done, so users who want to edit the Markdown directly can do so. You can even type Markdown into the new editor and it will automatically format the text as you type.
|
||||
|
||||
GitLab 14.0 introduces the [Content Editor](https://gitlab.com/groups/gitlab-org/-/epics/5401) into the Wiki with support for most of the basic Markdown content types like headers, bold and italic text, lists, code blocks, and links. [Full support](https://gitlab.com/groups/gitlab-org/-/epics/5438) for the entire [GitLab Flavored Markdown specification](https://docs.gitlab.com/ee/user/markdown.html) will arrive in upcoming releases. We also plan to make the Content Editor available in other areas of GitLab in the future. We welcome input on this early MVC in [this feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/332629).
|
||||
stage: Create
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Free, Premium, Ultimate]
|
||||
url: https://docs.gitlab.com/ee/user/project/wiki/#content-editor
|
||||
image_url: https://about.gitlab.com/images/14_0/wiki-content-editor-demo.gif
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Change an issue's type
|
||||
body: |
|
||||
In some cases, you may wish to change an issue's type. For example, you may want to escalate an issue to an [incident](https://docs.gitlab.com/ee/operations/incident_management/index.html) to ensure that your team handles the problem properly. To change an issue's type, edit the issue and select an issue type from the **Issue type** selector menu.
|
||||
stage: Monitor
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Free, Premium, Ultimate]
|
||||
url: https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#change-the-issue-type
|
||||
image_url: https://about.gitlab.com/images/14_0/change_type_on_issues.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Prepopulate the CI/CD pipeline editor with an initial template
|
||||
body: |
|
||||
The pipeline editor in GitLab is your one-stop shop when interacting with CI/CD pipelines. Previously, when writing your first pipeline with the editor, you were presented with a blank configuration. While perfectly useful for experienced pipeline authors, it was a bit of a leap for those just starting out.
|
||||
|
||||
In this release, if a project does not have a pipeline configured, the editor preloads a template showing an example 3-stage pipeline. You can save and run this pipeline right away to see it in action in your project. On top of that, it also has comments that help you understand the syntax, and tips and hints to help you start customizing the template to match your needs. It is now much easier to get your first green pipeline!
|
||||
stage: Verify
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Free, Premium, Ultimate]
|
||||
url: https://docs.gitlab.com/ee/ci/pipeline_editor/
|
||||
image_url: https://about.gitlab.com/images/14_0/template.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
- title: Terraform module registry built into GitLab
|
||||
body: |
|
||||
Terraform modules play a central role in building standard infrastructure components throughout an organization. Up to GitLab 13.12, GitLab users had to use either a third-party Terraform module registry, local modules, or Git-based modules. While these options work well, they do not help with the distribution of the modules and they lack proper versioning support, which introduces risks for module users. GitLab 14.0 extends our [Infrastructure-as-Code offerings](https://docs.gitlab.com/ee/user/infrastructure/) with a Terraform module registry. Now, you can use the Terraform module registry built into GitLab to discover Terraform modules with semantic versioning support for upgrades and maintenance. Moreover, you can publish modules easily using GitLab CI/CD.
|
||||
|
||||
While following Terraform's best practices, we recommend developing each Terraform module in a dedicated GitLab project. To simplify the transition to the registry, users can host and publish multiple modules from a single GitLab repository. You can learn more about publishing and consuming a new module [in our documentation](https://docs.gitlab.com/ee/user/packages/terraform_module_registry/index.html).
|
||||
stage: Configure
|
||||
self-managed: true
|
||||
gitlab-com: true
|
||||
packages: [Free, Premium, Ultimate]
|
||||
url: https://docs.gitlab.com/ee/user/packages/terraform_module_registry/index.html
|
||||
image_url: https://about.gitlab.com/images/14_0/terraform-module-registry.png
|
||||
published_at: 2021-06-22
|
||||
release: 14.0
|
||||
|
|
@ -135,7 +135,7 @@ starting GitLab. For example:
|
|||
ENABLE_BULLET=true bundle exec rails s
|
||||
```
|
||||
|
||||
Bullet logs query problems to both the Rails log as well as the Chrome
|
||||
Bullet logs query problems to both the Rails log as well as the browser
|
||||
console.
|
||||
|
||||
As a follow up to finding `N+1` queries with Bullet, consider writing a [QueryRecoder test](query_recorder.md) to prevent a regression.
|
||||
|
|
|
|||
|
|
@ -513,14 +513,14 @@ Finished in 34.51 seconds (files took 0.76702 seconds to load)
|
|||
|
||||
#### Run `:js` spec in a visible browser
|
||||
|
||||
Run the spec with `CHROME_HEADLESS=0`, like this:
|
||||
Run the spec with `WEBDRIVER_HEADLESS=0`, like this:
|
||||
|
||||
```shell
|
||||
CHROME_HEADLESS=0 bin/rspec some_spec.rb
|
||||
WEBDRIVER_HEADLESS=0 bin/rspec some_spec.rb
|
||||
```
|
||||
|
||||
The test completes quickly, but this gives you an idea of what's happening.
|
||||
Using `live_debug` with `CHROME_HEADLESS=0` pauses the open browser, and does not
|
||||
Using `live_debug` with `WEBDRIVER_HEADLESS=0` pauses the open browser, and does not
|
||||
open the page again. This can be used to debug and inspect elements.
|
||||
|
||||
You can also add `byebug` or `binding.pry` to pause execution and [step through](../pry_debugging.md#stepping)
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ docker run \
|
|||
To run the tests from the `/qa` directory:
|
||||
|
||||
```shell
|
||||
CHROME_HEADLESS=false bin/qa Test::Instance::All http://localhost -- qa/specs/features/ee/browser_ui/3_create/jenkins/jenkins_build_status_spec.rb
|
||||
WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://localhost -- qa/specs/features/ee/browser_ui/3_create/jenkins/jenkins_build_status_spec.rb
|
||||
```
|
||||
|
||||
The test automatically spins up a Docker container for Jenkins and tear down once the test completes.
|
||||
|
|
@ -131,7 +131,7 @@ sudo nginx -s reload
|
|||
You could then run the tests from the `/qa` directory:
|
||||
|
||||
```shell
|
||||
CHROME_HEADLESS=false bin/qa Test::Instance::All http://gitlab-gitaly-cluster.test -- --tag gitaly_cluster
|
||||
WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://gitlab-gitaly-cluster.test -- --tag gitaly_cluster
|
||||
```
|
||||
|
||||
Once you have finished testing you can stop and remove the Docker containers:
|
||||
|
|
@ -160,13 +160,13 @@ You might see NGINX issues when you run `gdk start` or `gdk restart`. In that ca
|
|||
Navigate to the folder in `/your-gdk/gitlab/qa` and issue the command:
|
||||
|
||||
```shell
|
||||
QA_DEBUG=true CHROME_HEADLESS=false GITLAB_ADMIN_USERNAME=rootusername GITLAB_ADMIN_PASSWORD=rootpassword GITLAB_QA_ACCESS_TOKEN=your_token_here GITLAB_QA_ADMIN_ACCESS_TOKEN=your_token_here CLUSTER_API_URL=https://kubernetes.docker.internal:6443 bundle exec bin/qa Test::Instance::All https://[YOUR-PORT].qa-tunnel.gitlab.info/ -- qa/specs/features/browser_ui/8_monitor/all_monitor_core_features_spec.rb --tag kubernetes --tag orchestrated --tag requires_admin
|
||||
QA_DEBUG=true WEBDRIVER_HEADLESS=false GITLAB_ADMIN_USERNAME=rootusername GITLAB_ADMIN_PASSWORD=rootpassword GITLAB_QA_ACCESS_TOKEN=your_token_here GITLAB_QA_ADMIN_ACCESS_TOKEN=your_token_here CLUSTER_API_URL=https://kubernetes.docker.internal:6443 bundle exec bin/qa Test::Instance::All https://[YOUR-PORT].qa-tunnel.gitlab.info/ -- qa/specs/features/browser_ui/8_monitor/all_monitor_core_features_spec.rb --tag kubernetes --tag orchestrated --tag requires_admin
|
||||
```
|
||||
|
||||
The following includes more information on the command:
|
||||
|
||||
-`QA_DEBUG` - Set to `true` to verbosely log page object actions.
|
||||
-`CHROME_HEADLESS` - When running locally, set to `false` to allow Chrome tests to be visible - watch your tests being run.
|
||||
-`WEBDRIVER_HEADLESS` - When running locally, set to `false` to allow browser tests to be visible - watch your tests being run.
|
||||
-`GITLAB_ADMIN_USERNAME` - Admin username to use when adding a license.
|
||||
-`GITLAB_ADMIN_PASSWORD` - Admin password to use when adding a license.
|
||||
-`GITLAB_QA_ACCESS_TOKEN` and `GITLAB_QA_ADMIN_ACCESS_TOKEN` - A valid personal access token with the `api` scope. This is used for API access during tests, and is used in the version that staging is currently running. The `ADMIN_ACCESS_TOKEN` is from a user with admin access. Used for API access as an admin during tests.
|
||||
|
|
@ -279,7 +279,7 @@ Geo end-to-end tests can run locally against a [Geo GDK setup](https://gitlab.co
|
|||
Run from the [`qa/` directory](https://gitlab.com/gitlab-org/gitlab/-/blob/f7272b77e80215c39d1ffeaed27794c220dbe03f/qa) with both GDK Geo primary and Geo secondary instances running:
|
||||
|
||||
```shell
|
||||
CHROME_HEADLESS=false bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --without-setup
|
||||
WEBDRIVER_HEADLESS=false bundle exec bin/qa QA::EE::Scenario::Test::Geo --primary-address http://localhost:3001 --secondary-address http://localhost:3002 --without-setup
|
||||
```
|
||||
|
||||
### Using Geo in Docker
|
||||
|
|
@ -455,7 +455,7 @@ To run the LDAP tests on your local with TLS enabled, follow these steps:
|
|||
1. Run an LDAP test from [`gitlab/qa`](https://gitlab.com/gitlab-org/gitlab/-/tree/d5447ebb5f99d4c72780681ddf4dc25b0738acba/qa) directory:
|
||||
|
||||
```shell
|
||||
GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true CHROME_HEADLESS=false bin/qa Test::Instance::All https://gitlab.test qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb
|
||||
GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All https://gitlab.test qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb
|
||||
```
|
||||
|
||||
### Running LDAP tests with TLS disabled
|
||||
|
|
@ -483,5 +483,5 @@ To run the LDAP tests on your local with TLS disabled, follow these steps:
|
|||
1. Run an LDAP test from [`gitlab/qa`](https://gitlab.com/gitlab-org/gitlab/-/tree/d5447ebb5f99d4c72780681ddf4dc25b0738acba/qa) directory:
|
||||
|
||||
```shell
|
||||
GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true CHROME_HEADLESS=false bin/qa Test::Instance::All http://localhost qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb
|
||||
GITLAB_LDAP_USERNAME="tanuki" GITLAB_LDAP_PASSWORD="password" QA_DEBUG=true WEBDRIVER_HEADLESS=false bin/qa Test::Instance::All http://localhost qa/specs/features/browser_ui/1_manage/login/log_into_gitlab_via_ldap_spec.rb
|
||||
```
|
||||
|
|
|
|||
|
|
@ -17378,6 +17378,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_api_fuzzing_scans`
|
||||
|
||||
Number of users who have run a API Fuzzing scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607044126_user_api_fuzzing_scans.yml)
|
||||
|
||||
Group: `category::fuzz testing`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_container_scanning_jobs`
|
||||
|
||||
Distinct count per user of Container Scanning jobs run
|
||||
|
|
@ -17390,6 +17402,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_container_scanning_scans`
|
||||
|
||||
Number of users who have run a Container Scanning scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043902_user_container_scanning_scans.yml)
|
||||
|
||||
Group: `group::composition analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_coverage_fuzzing_jobs`
|
||||
|
||||
Missing description
|
||||
|
|
@ -17402,6 +17426,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_coverage_fuzzing_scans`
|
||||
|
||||
Number of users who have run a Coverage Fuzzing scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607044040_user_coverage_fuzzing_scans.yml)
|
||||
|
||||
Group: `category::fuzz testing`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_dast_jobs`
|
||||
|
||||
Count of DAST jobs
|
||||
|
|
@ -17414,6 +17450,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_dast_scans`
|
||||
|
||||
Number of users who have run a DAST scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043109_user_dast_scans.yml)
|
||||
|
||||
Group: `group::dynamic analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_dependency_scanning_jobs`
|
||||
|
||||
Total number of users running Dependency Scanning jobs
|
||||
|
|
@ -17426,6 +17474,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_dependency_scanning_scans`
|
||||
|
||||
Number of users who have run a Dependency Scanning scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043819_user_dependency_scanning_scans.yml)
|
||||
|
||||
Group: `group::composition analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_license_management_jobs`
|
||||
|
||||
Total number of users running License Scanning jobs
|
||||
|
|
@ -17462,6 +17522,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`, `premium`, `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_sast_scans`
|
||||
|
||||
Number of users who have run a SAST scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043741_user_sast_scans.yml)
|
||||
|
||||
Group: `group::static analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_secret_detection_jobs`
|
||||
|
||||
Count of Secret Detection Jobs
|
||||
|
|
@ -17474,6 +17546,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`, `premium`, `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_secret_detection_scans`
|
||||
|
||||
Number of users who have run a Secret Detection scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_all/20210607043957_user_secret_detection_scans.yml)
|
||||
|
||||
Group: `group::static analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage.secure.user_unique_users_all_secure_scanners`
|
||||
|
||||
Missing description
|
||||
|
|
@ -19418,6 +19502,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_api_fuzzing_scans`
|
||||
|
||||
Number of users who have run a API Fuzzing scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043622_user_api_fuzzing_scans.yml)
|
||||
|
||||
Group: `category::fuzz testing`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_container_scanning_jobs`
|
||||
|
||||
Distinct count per user of Container Scanning jobs run monthly
|
||||
|
|
@ -19430,6 +19526,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_container_scanning_scans`
|
||||
|
||||
Number of users who have run a Container Scanning scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043336_user_container_scanning_scans.yml)
|
||||
|
||||
Group: `group::composition analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_coverage_fuzzing_jobs`
|
||||
|
||||
Missing description
|
||||
|
|
@ -19442,6 +19550,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_coverage_fuzzing_scans`
|
||||
|
||||
Number of users who have run a Coverage Fuzzing scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043509_user_coverage_fuzzing_scans.yml)
|
||||
|
||||
Group: `category::fuzz testing`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_dast_jobs`
|
||||
|
||||
Users who run a DAST job
|
||||
|
|
@ -19454,6 +19574,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_dast_scans`
|
||||
|
||||
Number of users who have run a DAST scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607041718_user_dast_scans.yml)
|
||||
|
||||
Group: `group::dynamic analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_dependency_scanning_jobs`
|
||||
|
||||
Monthly number of users creating Dependency Scanning jobs
|
||||
|
|
@ -19466,6 +19598,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_dependency_scanning_scans`
|
||||
|
||||
Number of users who have run a Dependency Scanning scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043301_user_dependency_scanning_scans.yml)
|
||||
|
||||
Group: `group::composition analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_license_management_jobs`
|
||||
|
||||
Monthly number of users running License Scanning jobs
|
||||
|
|
@ -19502,6 +19646,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`, `premium`, `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_sast_scans`
|
||||
|
||||
Number of users who have run a SAST scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043218_user_sast_scans.yml)
|
||||
|
||||
Group: `group::static analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_secret_detection_jobs`
|
||||
|
||||
Users who run a Secret Detection job
|
||||
|
|
@ -19514,6 +19670,18 @@ Status: `data_available`
|
|||
|
||||
Tiers: `free`, `premium`, `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_secret_detection_scans`
|
||||
|
||||
Number of users who have run a Secret Detection scan
|
||||
|
||||
[YAML definition](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/config/metrics/counts_28d/20210607043410_user_secret_detection_scans.yml)
|
||||
|
||||
Group: `group::static analysis`
|
||||
|
||||
Status: `data_available`
|
||||
|
||||
Tiers: `ultimate`
|
||||
|
||||
### `usage_activity_by_stage_monthly.secure.user_unique_users_all_secure_scanners`
|
||||
|
||||
Missing description
|
||||
|
|
|
|||
|
|
@ -45,13 +45,15 @@ module Banzai
|
|||
return
|
||||
end
|
||||
|
||||
html_attr.value =
|
||||
path =
|
||||
if context[:only_path]
|
||||
path
|
||||
else
|
||||
Addressable::URI.join(Gitlab.config.gitlab.base_url, path).to_s
|
||||
end
|
||||
|
||||
replace_html_attr_value(html_attr, path)
|
||||
|
||||
if html_attr.name == 'href'
|
||||
html_attr.parent.set_attribute('data-link', 'true')
|
||||
end
|
||||
|
|
@ -59,6 +61,21 @@ module Banzai
|
|||
html_attr.parent.add_class('gfm')
|
||||
end
|
||||
|
||||
def replace_html_attr_value(html_attr, path)
|
||||
if path != html_attr.value
|
||||
preserve_original_link(html_attr, html_attr.parent)
|
||||
end
|
||||
|
||||
html_attr.value = path
|
||||
end
|
||||
|
||||
def preserve_original_link(html_attr, node)
|
||||
return if html_attr.blank?
|
||||
return if node.value?('data-canonical-src')
|
||||
|
||||
node.set_attribute('data-canonical-src', html_attr.value)
|
||||
end
|
||||
|
||||
def group
|
||||
context[:group]
|
||||
end
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ module Banzai
|
|||
protected
|
||||
|
||||
def process_link(link_attr, node)
|
||||
process_link_attr(link_attr)
|
||||
process_link_attr(link_attr, node)
|
||||
remove_unsafe_links({ node: node }, remove_invalid_links: false)
|
||||
end
|
||||
|
||||
|
|
@ -44,14 +44,27 @@ module Banzai
|
|||
!context[:wiki].nil?
|
||||
end
|
||||
|
||||
def process_link_attr(html_attr)
|
||||
def process_link_attr(html_attr, node)
|
||||
return if html_attr.blank?
|
||||
|
||||
html_attr.value = apply_rewrite_rules(html_attr.value)
|
||||
rewritten_value = apply_rewrite_rules(html_attr.value)
|
||||
|
||||
if html_attr.value != rewritten_value
|
||||
preserve_original_link(html_attr, node)
|
||||
end
|
||||
|
||||
html_attr.value = rewritten_value
|
||||
rescue URI::Error, Addressable::URI::InvalidURIError
|
||||
# noop
|
||||
end
|
||||
|
||||
def preserve_original_link(html_attr, node)
|
||||
return if html_attr.blank?
|
||||
return if node.value?('data-canonical-src')
|
||||
|
||||
node.set_attribute('data-canonical-src', html_attr.value)
|
||||
end
|
||||
|
||||
def apply_rewrite_rules(link_string)
|
||||
Rewriter.new(link_string, wiki: context[:wiki], slug: context[:page_slug]).apply_rules
|
||||
end
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ module Gitlab
|
|||
module Utils
|
||||
module SanitizeNodeLink
|
||||
UNSAFE_PROTOCOLS = %w(data javascript vbscript).freeze
|
||||
ATTRS_TO_SANITIZE = %w(href src data-src).freeze
|
||||
ATTRS_TO_SANITIZE = %w(href src data-src data-canonical-src).freeze
|
||||
|
||||
def remove_unsafe_links(env, remove_invalid_links: true)
|
||||
node = env[:node]
|
||||
|
|
|
|||
|
|
@ -89,8 +89,8 @@ module QA
|
|||
# Chrome won't work properly in a Docker container in sandbox mode
|
||||
options.add_argument("no-sandbox")
|
||||
|
||||
# Run headless by default unless CHROME_HEADLESS is false
|
||||
if QA::Runtime::Env.chrome_headless?
|
||||
# Run headless by default unless WEBDRIVER_HEADLESS is false
|
||||
if QA::Runtime::Env.webdriver_headless?
|
||||
options.add_argument("headless")
|
||||
|
||||
# Chrome documentation says this flag is needed for now
|
||||
|
|
|
|||
|
|
@ -1,5 +1,6 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'active_support/deprecation'
|
||||
require 'gitlab/qa'
|
||||
require 'uri'
|
||||
|
||||
|
|
@ -64,9 +65,13 @@ module QA
|
|||
ENV['QA_LOG_PATH'] || $stdout
|
||||
end
|
||||
|
||||
# set to 'false' to have Chrome run visibly instead of headless
|
||||
def chrome_headless?
|
||||
enabled?(ENV['CHROME_HEADLESS'])
|
||||
# set to 'false' to have the browser run visibly instead of headless
|
||||
def webdriver_headless?
|
||||
if ENV.key?('CHROME_HEADLESS')
|
||||
ActiveSupport::Deprecation.warn("CHROME_HEADLESS is deprecated. Use WEBDRIVER_HEADLESS instead.")
|
||||
end
|
||||
|
||||
enabled?(ENV['WEBDRIVER_HEADLESS']) || enabled?(ENV['CHROME_HEADLESS'])
|
||||
end
|
||||
|
||||
# set to 'true' to have Chrome use a fixed profile directory
|
||||
|
|
|
|||
|
|
@ -54,10 +54,15 @@ RSpec.describe QA::Runtime::Env do
|
|||
default: false
|
||||
end
|
||||
|
||||
describe '.chrome_headless?' do
|
||||
describe '.webdriver_headless?' do
|
||||
before do
|
||||
# We need to set this because we have a fallback for CHROME_HEADLESS
|
||||
stub_env('CHROME_HEADLESS', 'false')
|
||||
end
|
||||
|
||||
it_behaves_like 'boolean method',
|
||||
method: :chrome_headless?,
|
||||
env_key: 'CHROME_HEADLESS',
|
||||
method: :webdriver_headless?,
|
||||
env_key: 'WEBDRIVER_HEADLESS',
|
||||
default: true
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ RSpec.describe 'Multi-file editor new directory', :js do
|
|||
find('.js-ide-commit-mode').click
|
||||
|
||||
# Compact mode depends on the size of window. If it is shorter than MAX_WINDOW_HEIGHT_COMPACT,
|
||||
# (as it is with CHROME_HEADLESS=0), this initial commit button will exist. Otherwise, if it is
|
||||
# (as it is with WEBDRIVER_HEADLESS=0), this initial commit button will exist. Otherwise, if it is
|
||||
# taller (as it is by default with chrome headless) then the button will not exist.
|
||||
if page.has_css?('.qa-begin-commit-button')
|
||||
find('.qa-begin-commit-button').click
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ RSpec.describe 'Multi-file editor new file', :js do
|
|||
find('.js-ide-commit-mode').click
|
||||
|
||||
# Compact mode depends on the size of window. If it is shorter than MAX_WINDOW_HEIGHT_COMPACT,
|
||||
# (as it is with CHROME_HEADLESS=0), this initial commit button will exist. Otherwise, if it is
|
||||
# (as it is with WEBDRIVER_HEADLESS=0), this initial commit button will exist. Otherwise, if it is
|
||||
# taller (as it is by default with chrome headless) then the button will not exist.
|
||||
if page.has_css?('.qa-begin-commit-button')
|
||||
find('.qa-begin-commit-button').click
|
||||
|
|
|
|||
|
|
@ -42,6 +42,12 @@ RSpec.describe Banzai::Filter::UploadLinkFilter do
|
|||
let(:upload_path) { '/uploads/e90decf88d8f96fe9e1389afc2e4a91f/test.jpg' }
|
||||
let(:relative_path) { "/#{project.full_path}#{upload_path}" }
|
||||
|
||||
it 'preserves original url in data-canonical-src attribute' do
|
||||
doc = filter(link(upload_path))
|
||||
|
||||
expect(doc.at_css('a')['data-canonical-src']).to eq(upload_path)
|
||||
end
|
||||
|
||||
context 'to a project upload' do
|
||||
context 'with an absolute URL' do
|
||||
let(:absolute_path) { Gitlab.config.gitlab.url + relative_path }
|
||||
|
|
|
|||
|
|
@ -22,6 +22,24 @@ RSpec.describe Banzai::Filter::WikiLinkFilter do
|
|||
expect(filtered_link.attribute('href').value).to eq('/uploads/a.test')
|
||||
end
|
||||
|
||||
describe 'when links are rewritable' do
|
||||
it "stores original url in the data-canonical-src attribute" do
|
||||
original_path = "#{repository_upload_folder}/a.jpg"
|
||||
filtered_elements = filter("<a href='#{original_path}'><img src='#{original_path}'>example</img></a>", wiki: wiki)
|
||||
|
||||
expect(filtered_elements.search('img').first.attribute('data-canonical-src').value).to eq(original_path)
|
||||
expect(filtered_elements.search('a').first.attribute('data-canonical-src').value).to eq(original_path)
|
||||
end
|
||||
end
|
||||
|
||||
describe 'when links are not rewritable' do
|
||||
it "does not store original url in the data-canonical-src attribute" do
|
||||
filtered_link = filter("<a href='/uploads/a.test'>Link</a>", wiki: wiki).children[0]
|
||||
|
||||
expect(filtered_link.value?('data-canonical-src')).to eq(false)
|
||||
end
|
||||
end
|
||||
|
||||
describe 'when links point to the relative wiki path' do
|
||||
it 'does not rewrite links' do
|
||||
path = "#{wiki.wiki_base_path}/#{repository_upload_folder}/a.jpg"
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ RSpec.describe Emails::Releases do
|
|||
let(:release) { create(:release, project: project, description: "Attachment: [Test file](#{upload_path})") }
|
||||
|
||||
it 'renders absolute links' do
|
||||
is_expected.to have_body_text(%Q(<a href="#{project.web_url}#{upload_path}" data-link="true" class="gfm">Test file</a>))
|
||||
is_expected.to have_body_text(%Q(<a href="#{project.web_url}#{upload_path}" data-canonical-src="#{upload_path}" data-link="true" class="gfm">Test file</a>))
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ RSpec.describe Emails::ServiceDesk do
|
|||
let_it_be(:note) { create(:note_on_issue, noteable: issue, project: project, note: "a new comment with [file](#{upload_path})") }
|
||||
|
||||
let(:template_content) { 'some text %{ NOTE_TEXT }' }
|
||||
let(:expected_body) { %Q(some text a new comment with <a href="#{project.web_url}#{upload_path}" data-link="true" class="gfm">file</a>) }
|
||||
let(:expected_body) { %Q(some text a new comment with <a href="#{project.web_url}#{upload_path}" data-canonical-src="#{upload_path}" data-link="true" class="gfm">file</a>) }
|
||||
|
||||
it_behaves_like 'handle template content', 'new_note'
|
||||
end
|
||||
|
|
|
|||
|
|
@ -60,8 +60,8 @@ Capybara.register_driver :chrome do |app|
|
|||
# Chrome won't work properly in a Docker container in sandbox mode
|
||||
options.add_argument("no-sandbox")
|
||||
|
||||
# Run headless by default unless CHROME_HEADLESS specified
|
||||
options.add_argument("headless") unless ENV['CHROME_HEADLESS'] =~ /^(false|no|0)$/i
|
||||
# Run headless by default unless WEBDRIVER_HEADLESS specified
|
||||
options.add_argument("headless") unless ENV['WEBDRIVER_HEADLESS'] =~ /^(false|no|0)$/i || ENV['CHROME_HEADLESS'] =~ /^(false|no|0)$/i
|
||||
|
||||
# Disable /dev/shm use in CI. See https://gitlab.com/gitlab-org/gitlab/issues/4252
|
||||
options.add_argument("disable-dev-shm-usage") if ENV['CI'] || ENV['CI_SERVER']
|
||||
|
|
|
|||
|
|
@ -7,8 +7,8 @@ module LiveDebugger
|
|||
puts
|
||||
puts "Current example is paused for live debugging."
|
||||
|
||||
if ENV['CHROME_HEADLESS'] =~ /^(false|no|0)$/i
|
||||
puts "Switch to the Chrome window that was automatically opened to run the test in order to view current page"
|
||||
if is_headless_disabled?
|
||||
puts "Switch to the browser window that was automatically opened to run the test in order to view current page"
|
||||
else
|
||||
puts "Opening #{current_url} in your default browser..."
|
||||
end
|
||||
|
|
@ -16,10 +16,16 @@ module LiveDebugger
|
|||
puts "The current user credentials are: #{@current_user.username} / #{@current_user.password}" if @current_user
|
||||
puts "Press any key to resume the execution of the example!!"
|
||||
|
||||
`open #{current_url}` if ENV['CHROME_HEADLESS'] !~ /^(false|no|0)$/i
|
||||
`open #{current_url}` if is_headless_disabled?
|
||||
|
||||
loop until $stdin.getch
|
||||
|
||||
puts "Back to the example!"
|
||||
end
|
||||
|
||||
def is_headless_disabled?
|
||||
ActiveSupport::Deprecation.warn("CHROME_HEADLESS is deprecated. Use WEBDRIVER_HEADLESS instead.") if ENV.key?('CHROME_HEADLESS')
|
||||
|
||||
ENV['WEBDRIVER_HEADLESS'] =~ /^(false|no|0)$/i || ENV['CHROME_HEADLESS'] =~ /^(false|no|0)$/i
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue