Automatic merge of gitlab-org/gitlab master

config/feature_flags/development/gitaly_pack_objects_hook_with_sidechannel.yml

+---
+name: gitaly_pack_objects_hook_with_sidechannel
+introduced_by_url: https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3758
+rollout_issue_url: https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1187
+milestone: '14.3'
+type: development
+group: 'team::Scalability'
+default_enabled: false

doc/ci/yaml/index.md

@@ -1594,6 +1594,14 @@ production:
 
 #### Requirements and limitations
 
+- The maximum number of jobs that a single job can need in the `needs:` array is limited:
+  - For GitLab.com, the limit is 50. For more information, see our
+    [infrastructure issue](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/7541).
+  - For self-managed instances, the default limit is 50. This limit [can be changed](#changing-the-needs-job-limit).
+- If `needs:` refers to a job that uses the [`parallel`](#parallel) keyword,
+  it depends on all jobs created in parallel, not just one job. It also downloads
+  artifacts from all the parallel jobs by default. If the artifacts have the same
+  name, they overwrite each other and only the last one downloaded is saved.
 - In [GitLab 14.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/30632) you
   can refer to jobs in the same stage as the job you are configuring. This feature is
   enabled on GitLab.com and ready for production use. On self-managed [GitLab 14.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/30632)
@@ -1603,17 +1611,6 @@ production:
   in a job's `needs:` section.
 - In GitLab 13.9 and older, if `needs:` refers to a job that might not be added to
   a pipeline because of `only`, `except`, or `rules`, the pipeline might fail to create.
-- The maximum number of jobs that a single job can need in the `needs:` array is limited:
-  - For GitLab.com, the limit is 50. For more information, see our
-    [infrastructure issue](https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/7541).
-  - For self-managed instances, the limit is: 50. This limit [can be changed](#changing-the-needs-job-limit).
-- If `needs:` refers to a job that uses the [`parallel`](#parallel) keyword,
-  it depends on all jobs created in parallel, not just one job. It also downloads
-  artifacts from all the parallel jobs by default. If the artifacts have the same
-  name, they overwrite each other and only the last one downloaded is saved.
-- `needs:` is similar to `dependencies:` in that it must use jobs from prior stages,
-  meaning it's impossible to create circular dependencies. Depending on jobs in the
-  current stage is not possible either, but [an issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/30632).
 
 ##### Changing the `needs:` job limit **(FREE SELF)**
 

doc/user/application_security/dependency_scanning/index.md

@@ -147,7 +147,7 @@ table.supported-languages ul {
     </tr>
     <tr>
       <td rowspan="2">Java</td>
-      <td><a href="https://gradle.org/">Gradle</a></td>
+      <td><a href="https://gradle.org/">Gradle</a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers">1</a></b></sup></td>
       <td>Any</td>
       <td>
         <ul>
@@ -228,7 +228,7 @@ table.supported-languages ul {
       <td>
         <ul>
             <li><a href="https://pipenv.pypa.io/en/latest/basics/#example-pipfile-pipfile-lock"><code>Pipfile</code></a></li>
-            <li><a href="https://pipenv.pypa.io/en/latest/basics/#example-pipfile-pipfile-lock"><code>Pipfile.lock</code></a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers">1</a></b></sup></li>
+            <li><a href="https://pipenv.pypa.io/en/latest/basics/#example-pipfile-pipfile-lock"><code>Pipfile.lock</code></a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers">2</a></b></sup></li>
         </ul>
       </td>
       <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td>
@@ -236,7 +236,7 @@ table.supported-languages ul {
     </tr>
     <tr>
       <td>Scala</td>
-      <td><a href="https://www.scala-sbt.org/">sbt</a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers">2</a></b></sup></td>
+      <td><a href="https://www.scala-sbt.org/">sbt</a><sup><b><a href="#notes-regarding-supported-languages-and-package-managers">3</a></b></sup></td>
       <td>Any</td>
       <td><code>build.sbt</code></td>
       <td><a href="https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium">Gemnasium</a></td>
@@ -247,6 +247,8 @@ table.supported-languages ul {
 
 ### Notes regarding supported languages and package managers
 
+1. Although Gradle with Java 8 is supported, there are other issues such that Android project builds are not supported at this time. Please see the backlog issue [Android support for Dependency Scanning (gemnasium-maven)](https://gitlab.com/gitlab-org/gitlab/-/issues/336866) for more details.
+
 1. The presence of a `Pipfile.lock` file alone will _not_ trigger the analyzer; the presence of a `Pipfile` is still required in order
 for the analyzer to be executed. However, if a `Pipfile.lock` file is found, it will be used by `Gemnasium` to scan the exact package
 versions listed in this file.

ee/app/assets/javascripts/security_configuration/dast_profiles/README.md

+# DAST profiles components
+
+This document's purpose is to give a broad overview of how DAST profiles apps are structured.
+This summary is deliberately abstract so that it doesn't require frequent updates whenever features are
+added, changed, or removed in DAST profiles.
+
+## DAST profiles list
+
+The DAST profiles list relies on 4 main components that orchestrate the rendering of both profile
+types.
+
+- `DastProfiles` is the top-level component. It acts as the data layer by communicating with the
+  GraphQL API and rewriting the cache as needed. It renders the profile-specific components and
+  ensures they receive the updated data through props and events.
+- `DastSiteProfilesList` and `DastScannerProfilesList` are the profile-specific components. They
+  can implement some logic specific to a profile type if needed. Their rendering is delegated to
+  a shared `DastProfilesList` component that can be extended through slots.
+- `DastProfilesList` is responsible for actually rendering a profiles list. As stated above, it
+  is rendered by a profile-specific component that provides profiles data and optionally customizes
+  what's displayed using slots.
+
+```mermaid
+graph TD;
+  subgraph Profile list;
+  DP(dast_profiles.vue)
+  SCPL[dast_scanner_profiles_list.vue]
+  SIPL[dast_site_profiles_list.vue]
+  DPL[dast_profiles_list.vue]
+  DP -- render --> SCPL
+  DP -- render --> SIPL
+  SCPL -- render --> DPL
+  SIPL -- render --> DPL
+  end;
+```
+
+## DAST profiles forms
+
+To render DAST profile forms, we have 3 components and a mixin.
+A base component implements all the logic that can be shared across both profile types, including: form
+submission, saving a profile, rendering the form's control. For the specific data and behaviors, we have two
+profile-specific components
+
+- `BaseDastProfileForm` implements the logic that can be shared across both profile types like form
+  submission, saving a profile, rendering the form's control, etc.
+- `DastSiteProfileForm` and `DastScannerProfileForm` are profile-specific. They hold the form data
+  and they both render the base component mentioned above. Among other things, they pass computed
+  GraphQL options to the base component via props so that the mutations can be triggered properly.
+  The base component's template is extended with the profile-specific form fields.
+- `dastProfileFormMixin` is the mixin that both profile-specific components leverage to share some
+  common options like props, computed props, etc.
+
+```mermaid
+graph TD;
+  subgraph Site and Scanner profile forms;
+  M(dast_profile_form_mixin.js)
+  SC[dast_scanner_profile_form.vue]
+  SI[dast_site_profile_form.vue]
+  B(base_dast_profile_form.vue)
+  M -- included --> SC
+  M -- included --> SI
+  SC -- render --> B
+  SI -- render --> B
+  end;
+```
+
+## DAST profile selectors
+
+Profile selectors can be used to associate DAST site and scanner profiles with an on-demand DAST
+scan, or when configuring DAST for a project. Thus, they have been abstracted out in a reusable
+component that itself relies on a set of reusable components.
+
+- `DastProfilesSelector` is the main component that fetches the profiles and renders the
+  profile-specific selectors.
+- `ScannerProfileSelector` and `SiteProfileSelector` both render two common base components that they
+  extend through props and slots.
+- `ProfileSelector` is the base component responsible for rendering the actual selector.
+- `ScannerProfileSummary` and `SiteProfileSummary` are the base components responsible for rendering selected profiles'
+  summary. It relies on `SummaryCell` to render each data-point in the summary.
+
+```mermaid
+graph TB;
+  S(dast_profiles_selector.vue)
+  ScannerSelector[scanner_profile_selector.vue]
+  SiteSelector[site_profile_selector.vue]
+  PS[profile_selector.vue]
+  ScannerSelectorSummary[scanner_profile_summary.vue]
+  SiteSelectorSummary[site_profile_summary.vue]
+  ProfileSelectorSummaryCell[summary_cell.vue]
+
+  subgraph Selector;
+    direction TB;
+    S --> ScannerSelector
+    S --> SiteSelector
+    ScannerSelector --> PS
+    SiteSelector --> PS
+  end;
+
+  subgraph Profile summary;
+    direction TB;
+    ScannerSelector --> ScannerSelectorSummary
+    ScannerSelectorSummary --> ProfileSelectorSummaryCell
+    SiteSelector -->SiteSelectorSummary
+    SiteSelectorSummary --> ProfileSelectorSummaryCell
+  end;
+```