Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-12-17 21:13:34 +00:00
parent d70200a2d3
commit 6bdb805dc8
12 changed files with 116 additions and 40 deletions

View file

@ -32,7 +32,7 @@
type_plural: type_plural,
active_tokens: @active_personal_access_tokens,
revoke_route_helper: ->(token) { revoke_profile_personal_access_token_path(token) }
- if Feature.enabled?(:hide_access_tokens)
- if Feature.enabled?(:hide_access_tokens, default_enabled: :yaml)
#js-tokens-app{ data: { tokens_data: tokens_app_data } }
- else
- unless Gitlab::CurrentSettings.disable_feed_token

View file

@ -74,25 +74,44 @@
= s_('ProjectsNew|Allows you to immediately clone this projects repository. Skip this if you plan to push up an existing repository.')
- experiment(:new_project_sast_enabled, user: current_user) do |e|
.form-group
.form-check.gl-mb-3
- e.try(:candidate) do
- e.try(:candidate) do
.form-group
.form-check.gl-mb-3
= check_box_tag 'project[initialize_with_sast]', '1', true, class: 'form-check-input', data: { qa_selector: 'initialize_with_sast_checkbox', track_experiment: e.name, track_label: track_label, track_action: 'activate_form_input', track_property: 'init_with_sast' }
= label_tag 'project[initialize_with_sast]', class: 'form-check-label' do
= s_('ProjectsNew|Enable Static Application Security Testing (SAST)')
- e.try(:free_indicator) do
.form-text.text-muted
= s_('ProjectsNew|Analyze your source code for known security vulnerabilities.')
= link_to _('Learn more.'), help_page_path('user/application_security/sast/index'), target: '_blank', rel: 'noopener noreferrer', data: { track_action: 'followed', track_experiment: e.name }
- e.try(:unchecked_candidate) do
.form-group
.form-check.gl-mb-3
= check_box_tag 'project[initialize_with_sast]', '1', false, class: 'form-check-input', data: { qa_selector: 'initialize_with_sast_checkbox', track_experiment: e.name, track_label: track_label, track_action: 'activate_form_input', track_property: 'init_with_sast' }
= label_tag 'project[initialize_with_sast]', class: 'form-check-label' do
= s_('ProjectsNew|Enable Static Application Security Testing (SAST)')
.form-text.text-muted
= s_('ProjectsNew|Analyze your source code for known security vulnerabilities.')
= link_to _('Learn more.'), help_page_path('user/application_security/sast/index'), target: '_blank', rel: 'noopener noreferrer', data: { track_action: 'followed', track_experiment: e.name }
- e.try(:free_indicator) do
.form-group
.form-check.gl-mb-3
= check_box_tag 'project[initialize_with_sast]', '1', true, class: 'form-check-input', data: { qa_selector: 'initialize_with_sast_checkbox', track_experiment: e.name, track_label: track_label, track_action: 'activate_form_input', track_property: 'init_with_sast' }
= label_tag 'project[initialize_with_sast]', class: 'form-check-label' do
= s_('ProjectsNew|Enable Static Application Security Testing (SAST)')
%span.badge.badge-info.badge-pill.gl-badge.sm= _('Free')
- e.try(:unchecked_candidate) do
.form-text.text-muted
= s_('ProjectsNew|Analyze your source code for known security vulnerabilities.')
= link_to _('Learn more.'), help_page_path('user/application_security/sast/index'), target: '_blank', rel: 'noopener noreferrer', data: { track_action: 'followed', track_experiment: e.name }
- e.try(:unchecked_free_indicator) do
.form-group
.form-check.gl-mb-3
= check_box_tag 'project[initialize_with_sast]', '1', false, class: 'form-check-input', data: { qa_selector: 'initialize_with_sast_checkbox', track_experiment: e.name, track_label: track_label, track_action: 'activate_form_input', track_property: 'init_with_sast' }
= label_tag 'project[initialize_with_sast]', class: 'form-check-label' do
= s_('ProjectsNew|Enable Static Application Security Testing (SAST)')
.form-text.text-muted
= s_('ProjectsNew|Analyze your source code for known security vulnerabilities.')
= link_to _('Learn more.'), help_page_path('user/application_security/sast/index'), target: '_blank', rel: 'noopener noreferrer', data: { track_action: 'followed', track_experiment: e.name }
%span.badge.badge-info.badge-pill.gl-badge.sm= _('Free')
.form-text.text-muted
= s_('ProjectsNew|Analyze your source code for known security vulnerabilities.')
= link_to _('Learn more.'), help_page_path('user/application_security/sast/index'), target: '_blank', rel: 'noopener noreferrer', data: { track_action: 'followed', track_experiment: e.name }
= f.submit _('Create project'), class: "btn gl-button btn-confirm", data: { track_label: "#{track_label}", track_action: "click_button", track_property: "create_project", track_value: "" }
= link_to _('Cancel'), dashboard_projects_path, class: 'btn gl-button btn-default btn-cancel', data: { track_label: "#{track_label}", track_action: "click_button", track_property: "cancel", track_value: "" }

View file

@ -5,4 +5,4 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/347490
milestone: '14.6'
type: development
group: group::access
default_enabled: false
default_enabled: true

View file

@ -548,7 +548,7 @@ kubectl create configmap docker-daemon --namespace gitlab-runner --from-file /tm
```
NOTE:
Make sure to use the namespace that the GitLab Runner Kubernetes executor uses
Make sure to use the namespace that the Kubernetes executor for GitLab Runner uses
to create job pods in.
After the ConfigMap is created, you can update the `config.toml`

View file

@ -1600,7 +1600,7 @@ users be aware of recent improvements or additions.
The GitLab Technical Writing team determines which versions of
documentation to display on this site based on the GitLab
[Statement of Support](https://about.gitlab.com/support/statement-of-support.html#we-support-the-current-major-version-and-the-two-previous-major-versions).
[Statement of Support](https://about.gitlab.com/support/statement-of-support.html#version-support).
### View older GitLab documentation versions
@ -1653,6 +1653,13 @@ This feature does something.
This feature does something else.
```
If you're documenting elements of a feature, start with the feature name or a gerund:
```markdown
> - Notifications for expiring tokens [introduced](<link-to-issue>) in GitLab 11.3.
> - Creating an issue from an issue board [introduced](<link-to-issue>) in GitLab 13.1.
```
If a feature is moved to another tier:
```markdown

View file

@ -544,7 +544,7 @@ This outputs `1` followed by the content of `/etc/passwd`.
### TLS minimum recommended version
As we have [moved away from supporting TLS 1.0 and 1.1](https://about.gitlab.com/blog/2018/10/15/gitlab-to-deprecate-older-tls/), we should only use TLS 1.2 and above.
As we have [moved away from supporting TLS 1.0 and 1.1](https://about.gitlab.com/blog/2018/10/15/gitlab-to-deprecate-older-tls/), you must use TLS 1.2 and above.
#### Ciphers

View file

@ -233,7 +233,7 @@ that were not removed along with the Kubernetes resources.
The cluster is configured via Terraform in the [`engineering-productivity-infrastructure`](https://gitlab.com/gitlab-org/quality/engineering-productivity-infrastructure) project.
Node pool image type must be `Container-Optimized OS (cos)`, not `Container-Optimized OS with Containerd (cos_containerd)`,
due to this [known issue on GitLab Runner Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4755)
due to this [known issue on the Kubernetes executor for GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4755)
### Helm

View file

@ -213,7 +213,7 @@ is a good way to balance the needs of letting a developer's per-commit pipeline
and also giving the fuzzer a large amount of time to fully explore and test the app.
Long-running fuzzing jobs are usually necessary for the coverage guided fuzzer to find deeper bugs
in your latest codebase. THe following is an example of what `.gitlab-ci.yml` looks like in this
in your latest codebase. The following is an example of what `.gitlab-ci.yml` looks like in this
workflow (for the full example, see the [repository](https://gitlab.com/gitlab-org/security-products/demos/coverage-fuzzing/go-fuzzing-example/-/tree/continuous_fuzzing)):
```yaml

View file

@ -12,9 +12,39 @@ Try out Dependency Scanning in GitLab Ultimate.
[It's free for 30 days](https://about.gitlab.com/free-trial/index.html?glm_source=docs.gitlab.com&glm_content=u-dependency-scanning-docs).
The Dependency Scanning feature can automatically find security vulnerabilities in your
dependencies while you're developing and testing your applications. For example, dependency scanning
lets you know if your application uses an external (open source) library that is known to be
vulnerable. You can then take action to protect your application.
software dependencies while you're developing and testing your applications. For example,
dependency scanning lets you know if your application uses an external (open source)
library that is known to be vulnerable. You can then take action to protect your application.
Dependency Scanning is often considered part of Software Composition Analysis (SCA).
SCA can contain various aspects of inspecting the items used in your code. These items
typically include both application dependencies and system dependencies that are
almost always imported from external sources, rather than sourced from items you wrote yourself.
At GitLab, we use two separate scanning capabilities to ensure coverage for all of
these dependency types: Dependency Scanning and Container Scanning. Both are included
in GitLab Ultimate. We encourage you to use all of our scanners whenever possible
to cover as much of your risk area as possible:
- Dependency Scanning analyzes your project and tells you which software dependencies,
including upstream dependencies, have been included in your project, and what known
risks the dependencies contain. Dependency Scanning modifies its behavior based
on the language and package manager of the project. It typically looks for a lock file
then performs a build to fetch upstream dependency information. In the case of
containers, Dependency Scanning uses the compatible manifest and reports only these
declared software dependencies (and those installed as a sub-dependency).
Dependency Scanning can not detect software dependencies that are pre-bundled
into the container's base image. To identify pre-bundled dependencies, enable
[Container Scanning](../container_scanning/) language scanning using the
[`CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN` variable](../container_scanning/#report-language-specific-findings).
- [Container Scanning](../container_scanning/) analyzes your containers and tells
you about known risks in the operating system's (OS) packages. You can configure it
to also report on software and language dependencies, if you enable it and use
the [`CS_DISABLE_LANGUAGE_VULNERABILITY_SCAN` variable](../container_scanning/#report-language-specific-findings).
Turning this variable on can result in some duplicate findings, as we do not yet
de-duplicate results between Container Scanning and Dependency Scanning. For more details,
efforts to de-duplicate these findings can be tracked in
[this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/348655).
## Overview

View file

@ -42,7 +42,7 @@ To use the KAS:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7, the Agent manifest configuration can be added to multiple directories (or subdirectories) of its repository.
> - Group authorization was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3.
To configure an Agent, you need:
To create an agent, you need:
1. A GitLab repository to hold the configuration file.
1. Install the Agent in a cluster.
@ -58,28 +58,22 @@ In your repository, add the Agent configuration file under:
Make sure that `<agent-name>` conforms to the [Agent's naming format](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/identity_and_auth.md#agent-identity-and-name).
Your `config.yaml` file specifies all configurations of the Agent, such as:
- The manifest projects to synchronize.
- The groups that can access this Agent via the [CI/CD Tunnel](../ci_cd_tunnel.md).
- The address of the `hubble-relay` for the Network Security policy integrations.
WARNING:
The agent is only recognized if you use `.yaml` extension for the `config.yaml` file. The extension `.yml` is **not** recognized.
As an example, a minimal Agent configuration that sets up only the manifest
synchronizations is:
You **don't have to add any content** to this file when you create it. The fact that the file exists
tells GitLab that this is an agent configuration file. It doesn't do anything so far, but, later on, you can use this
file to [configure the agent](../repository.md) by setting up parameters such as:
```yaml
gitops:
manifest_projects:
# The `id` is the path to the Git repository holding your manifest files
- id: "path/to/your-manifest-project-1"
paths:
- glob: '/**/*.{yaml,yml,json}'
```
- Groups and projects that can access the agent via the [CI/CD Tunnel](../ci_cd_tunnel.md).
- [Manifest projects to synchronize](../repository.md#synchronize-manifest-projects).
- The address of the `hubble-relay` for the [Network Security policy integrations](../../../project/clusters/protect/index.md).
All the options for the [Agent configuration repository](../repository.md) are documented separately.
To see all the settings available, read the [Agent configuration repository documentation](../repository.md).
### Access your cluster from GitLab CI/CD
Use the [CI/CD Tunnel](../ci_cd_tunnel.md#example-for-a-kubectl-command-using-the-cicd-tunnel) to access your cluster from GitLab CI/CD.
### Create an Agent record in GitLab

View file

@ -113,7 +113,7 @@ module Gitlab
name: build[:name],
stage: build[:stage],
image: build.dig(:options, :image, :name),
services: build.dig(:options, :services)&.map { |service| service[:name] },
services: service_names(build),
script: [
build.dig(:options, :before_script),
build.dig(:options, :script),
@ -122,6 +122,14 @@ module Gitlab
}
end
def service_names(build)
services = build.dig(:options, :services)
return unless services
services.compact.map { |service| service[:name] }
end
def stages_attributes
command.yaml_processor_result.stages_attributes
end

View file

@ -24,6 +24,7 @@ RSpec.describe Gitlab::Ci::Pipeline::Chain::Validate::External do
second_stage_job_name:
stage: second_stage
services:
-
- postgres
before_script:
- echo 'first hello'
@ -142,6 +143,23 @@ RSpec.describe Gitlab::Ci::Pipeline::Chain::Validate::External do
perform!
end
it 'returns expected payload' do
expect(::Gitlab::HTTP).to receive(:post) do |_url, params|
payload = Gitlab::Json.parse(params[:body])
builds = payload['builds']
expect(builds.count).to eq(2)
expect(builds[0]['services']).to be_nil
expect(builds[0]['stage']).to eq('first_stage')
expect(builds[0]['image']).to eq('hello_world')
expect(builds[1]['services']).to eq(['postgres'])
expect(builds[1]['stage']).to eq('second_stage')
expect(builds[1]['image']).to be_nil
end
perform!
end
end
context 'when EXTERNAL_VALIDATION_SERVICE_TOKEN is set' do