diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-10-11 21:09:43 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-10-11 21:09:43 +0300 |
commit | 6e7be08ca5d6fac981284e7b1383b320a03d3a5d (patch) | |
tree | 5ae3da5b41f79107b86874c393a2799b7d1b1f3c /doc/development | |
parent | 14ae125e1c59ca3e9b535938707831c986dbbc43 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development')
-rw-r--r-- | doc/development/pipelines.md | 5 | ||||
-rw-r--r-- | doc/development/sec/index.md | 2 | ||||
-rw-r--r-- | doc/development/testing_guide/end_to_end/beginners_guide.md | 28 | ||||
-rw-r--r-- | doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md | 4 | ||||
-rw-r--r-- | doc/development/work_items.md | 4 |
5 files changed, 32 insertions, 11 deletions
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md index 047a2064f6f..360ebcc3e52 100644 --- a/doc/development/pipelines.md +++ b/doc/development/pipelines.md @@ -358,6 +358,11 @@ with latest `master`, and then it triggers a regular branch pipeline for never be merged back to `master`. Any other Ruby 3 changes should go into `master` directly, which should be compatible with Ruby 2.7. +Previously, `ruby3-sync` was using a project token stored in `RUBY3_SYNC_TOKEN` +(now backed up in `RUBY3_SYNC_TOKEN_NOT_USED`), however due to various +permissions issues, we ended up using an access token from `gitlab-bot` so now +`RUBY3_SYNC_TOKEN` is actually an access token from `gitlab-bot`. + ### Long-term plan We follow the [PostgreSQL versions shipped with Omnibus GitLab](../administration/package_information/postgresql_versions.md): diff --git a/doc/development/sec/index.md b/doc/development/sec/index.md index baea583e1ce..294dad4048a 100644 --- a/doc/development/sec/index.md +++ b/doc/development/sec/index.md @@ -45,7 +45,7 @@ flowchart LR ### Scanning The scanning part is responsible for finding vulnerabilities in given resources, and exporting results. -The scans are executed in CI/CD jobs via several small projects called [Analyzers](../../user/application_security/terminology/index.md#analyzer), which can be found in our [Analyzers sub-group](https://gitlab.com/gitlab-org/security-products/analyzers). +The scans are executed in CI/CD jobs via several small projects called [Analyzers](../../user/application_security/terminology/index.md#analyzer), which can be found in our [Analyzers subgroup](https://gitlab.com/gitlab-org/security-products/analyzers). The Analyzers are wrappers around security tools called [Scanners](../../user/application_security/terminology/index.md#scanner), developed internally or externally, to integrate them into GitLab. The Analyzers are mainly written in Go. diff --git a/doc/development/testing_guide/end_to_end/beginners_guide.md b/doc/development/testing_guide/end_to_end/beginners_guide.md index bceb0d12fde..b81379d89b2 100644 --- a/doc/development/testing_guide/end_to_end/beginners_guide.md +++ b/doc/development/testing_guide/end_to_end/beginners_guide.md @@ -120,6 +120,22 @@ module QA end ``` +### The `product_group` metadata + +Assign `product_group` metadata and specify what product group this test belongs to. In this case, `authentication_and_authorization`. + +```ruby +# frozen_string_literal: true + +module QA + RSpec.describe 'Manage' do + describe 'Login', product_group: :authentication_and_authorization do + + end + end +end +``` + ### The `it` blocks (examples) Every test suite contains at least one `it` block (example). A good way to start @@ -128,7 +144,7 @@ writing end-to-end tests is to write test case descriptions as `it` blocks: ```ruby module QA RSpec.describe 'Manage' do - describe 'Login' do + describe 'Login', product_group: :authentication_and_authorization do it 'can login' do end @@ -152,7 +168,7 @@ Begin by logging in. module QA RSpec.describe 'Manage' do - describe 'Login' do + describe 'Login', product_group: :authentication_and_authorization do it 'can login' do Flow::Login.sign_in @@ -175,7 +191,7 @@ should answer the question "What do we test?" module QA RSpec.describe 'Manage' do - describe 'Login' do + describe 'Login', product_group: :authentication_and_authorization do it 'can login' do Flow::Login.sign_in @@ -222,7 +238,7 @@ a call to `sign_in`. module QA RSpec.describe 'Manage' do - describe 'Login' do + describe 'Login', product_group: :authentication_and_authorization do before do Flow::Login.sign_in end @@ -251,7 +267,7 @@ ensuring we now sign in at the beginning of each test. ## Test setup using resources and page objects Next, let's test something other than Login. Let's test Issues, which are owned by the Plan -stage, so [create a file](#identify-the-devops-stage) in +stage and the Project Management Group, so [create a file](#identify-the-devops-stage) in `qa/specs/features/browser_ui/3_create/issues` called `issues_spec.rb`. ```ruby @@ -259,7 +275,7 @@ stage, so [create a file](#identify-the-devops-stage) in module QA RSpec.describe 'Plan' do - describe 'Issues' do + describe 'Issues', product_group: :project_management do let(:issue) do Resource::Issue.fabricate_via_api! do |issue| issue.title = 'My issue' diff --git a/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md b/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md index 3391c80aca0..0b7e1bd46da 100644 --- a/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md +++ b/doc/development/value_stream_analytics/value_stream_analytics_aggregated_backend.md @@ -43,7 +43,7 @@ Benefits of the aggregated VSA backend: - Simpler database queries (fewer JOINs). - Faster aggregations, only a single table is accessed. - Possibility to introduce further aggregations for improving the first page load time. -- Better performance for large groups (with many sub-groups, projects, issues and, merge requests). +- Better performance for large groups (with many subgroups, projects, issues and, merge requests). - Ready for database decomposition. The VSA related database tables could live in a separate database with a minimal development effort. - Ready for keyset pagination which can be useful for exporting the data. @@ -165,7 +165,7 @@ Creation time always happens first, so this stage always reports negative durati The data collection scans and processes all issues and merge requests records in the group hierarchy, starting from the top-level group. This means that if a group only has one value stream -in a sub-group, we nevertheless collect data of all issues and merge requests in the hierarchy of +in a subgroup, we nevertheless collect data of all issues and merge requests in the hierarchy of this group. This aims to simplify the data collection mechanism. Moreover, data research shows that most group hierarchies have their stages configured on the top level. diff --git a/doc/development/work_items.md b/doc/development/work_items.md index 5f0ef88f200..eabad175bf7 100644 --- a/doc/development/work_items.md +++ b/doc/development/work_items.md @@ -88,8 +88,8 @@ so that in future we can allow users to define custom WITs, we will move the to `work_item_types` will involve creating the set of WITs for all root-level groups. NOTE: -At first, defining a WIT will only be possible at the root-level group, which would then be inherited by sub-groups. -We will investigate the possibility of defining new WITs at sub-group levels at a later iteration. +At first, defining a WIT will only be possible at the root-level group, which would then be inherited by subgroups. +We will investigate the possibility of defining new WITs at subgroup levels at a later iteration. ### Introducing work_item_types table |