Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2019-09-25 06:06:16 +00:00
parent 7bb7a8d529
commit fbcb36880c
5 changed files with 23 additions and 98 deletions

View File

@ -14,6 +14,9 @@ class UpdateCsVulnerabilityConfidenceColumn < ActiveRecord::Migration[5.2]
# 137_424 records to be updated on GitLab.com,
# giving us an estimated runtime of 12 hours.
def up
# no-op in CE
return unless Gitlab.ee?
migration = Gitlab::BackgroundMigration::UpdateVulnerabilityConfidence
migration_name = migration.to_s.demodulize
relation = migration::Occurrence.container_scanning_reports_with_medium_confidence

View File

@ -986,6 +986,10 @@ The above script will:
> - Blocking manual actions were introduced in GitLab 9.0.
> - Protected actions were introduced in GitLab 9.2.
NOTE: **Note:**
Using `when:manual` and `trigger` together will result in the error `jobs:#{job-name} when should be on_success, on_failure or always`.
This is because `when:manual` will prevent any trigger from being used.
Manual actions are a special type of job that are not executed automatically,
they need to be explicitly started by a user. An example usage of manual actions
would be a deployment to a production environment. Manual actions can be started
@ -2064,6 +2068,10 @@ job split into three separate jobs.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/8997) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.8.
NOTE: **Note:**
Using a `trigger` with `when:manual` together it will result in the error `jobs:#{job-name} when should be on_success, on_failure or always`.
This is because `when:manual` will prevent any trigger from being used.
`trigger` allows you to define downstream pipeline trigger. When a job created
from `trigger` definition is started by GitLab, a downstream pipeline gets
created.

View File

@ -216,11 +216,18 @@ Do not include the same information in multiple places. [Link to a SSOT instead.
- Be clear, concise, and stick to the goal of the doc.
- Write in US English.
- Capitalize "G" and "L" in GitLab.
- Use title case when referring to [features](https://about.gitlab.com/features/) or
[products](https://about.gitlab.com/pricing/) (e.g., GitLab Runner, Geo,
Issue Boards, GitLab Core, Git, Prometheus, Kubernetes, etc), and methods or methodologies
(e.g., Continuous Integration, Continuous Deployment, Scrum, Agile, etc). Note that
some features are also objects (e.g. "GitLab's Merge Requests support X." and "Create a new merge request for Z.").
- Use title case when referring to:
- [GitLab Features](https://about.gitlab.com/features/). For example, Issue Board,
Geo, and Runner.
- GitLab [product tiers](https://about.gitlab.com/pricing/). For example, GitLab Core
and GitLab Ultimate.
- Third-party products. For example, Prometheus, Kubernetes, and Git.
- Methods or methodologies. For example, Continuous Integration, Continuous
Deployment, Scrum, and Agile.
NOTE: **Note:**
Some features are also objects. For example, "GitLab's Merge Requests support X." and
"Create a new merge request for Z.".
## Text

View File

@ -1,35 +0,0 @@
# frozen_string_literal: true
# rubocop:disable Style/Documentation
module Gitlab
module BackgroundMigration
class UpdateVulnerabilityConfidence
class Occurrence < ActiveRecord::Base
include ::EachBatch
self.table_name = 'vulnerability_occurrences'
REPORT_TYPES = {
container_scanning: 2
}.freeze
CONFIDENCE_LEVELS = {
unknown: 2,
medium: 5
}.freeze
enum confidences: CONFIDENCE_LEVELS
enum report_type: REPORT_TYPES
def self.container_scanning_reports_with_medium_confidence
where(report_type: self.report_types[:container_scanning], confidence: self.confidences[:medium])
end
end
def perform(start_id, stop_id)
Occurrence.container_scanning_reports_with_medium_confidence
.where(id: start_id..stop_id)
.update_all(confidence: Occurrence.confidences[:unknown])
end
end
end
end

View File

@ -1,58 +0,0 @@
# frozen_string_literal: true
require 'spec_helper'
describe Gitlab::BackgroundMigration::UpdateVulnerabilityConfidence, :migration, schema: 20190909141517 do
let(:vulnerabilities) { table(:vulnerability_occurrences) }
let(:identifiers) { table(:vulnerability_identifiers) }
let(:scanners) { table(:vulnerability_scanners) }
let(:projects) { table(:projects) }
let(:vul1) { attributes_for(:vulnerabilities_occurrence) }
let(:vul2) { attributes_for(:vulnerabilities_occurrence) }
let(:vul3) { attributes_for(:vulnerabilities_occurrence) }
it 'updates confidence level for container scanning reports' do
projects.create!(id: 123, namespace_id: 12, name: 'gitlab', path: 'gitlab')
(1..3).to_a.each do |identifier_id|
identifiers.create!(id: identifier_id,
project_id: 123,
fingerprint: 'd432c2ad2953e8bd587a3a43b3ce309b5b0154c' + identifier_id.to_s,
external_type: 'SECURITY_ID',
external_id: 'SECURITY_0',
name: 'SECURITY_IDENTIFIER 0')
end
scanners.create!(id: 6, project_id: 123, external_id: 'clair', name: 'Security Scanner')
vulnerabilities.create!(container_scanning_vuln_params(vul1, 1))
vulnerabilities.create!(container_scanning_vuln_params(vul2, 2))
vulnerabilities.create!(container_scanning_vuln_params(vul3, 3).merge(report_type: 1))
expect(vulnerabilities.where(report_type: 2, confidence: 2).count). to eq(0)
expect(vulnerabilities.exists?(report_type: 2, confidence: 5)).to be_truthy
described_class.new.perform(1, 3)
expect(vulnerabilities.exists?(report_type: 2, confidence: 5)).to be_falsy
expect(vulnerabilities.where(report_type: 2, confidence: 2).count). to eq(2)
end
def container_scanning_vuln_params(vul, primary_identifier_id)
{
id: vul[:id],
severity: 2,
confidence: 5,
report_type: 2,
project_id: 123,
scanner_id: 6,
primary_identifier_id: primary_identifier_id,
project_fingerprint: vul[:project_fingerprint],
location_fingerprint: vul[:location_fingerprint],
uuid: vul[:uuid],
name: vul[:name],
metadata_version: '1.3',
raw_metadata: vul3[:raw_metadata]
}
end
end