2016-09-09 07:34:28 -04:00
|
|
|
require 'sidekiq/testing'
|
2016-09-15 10:12:12 -04:00
|
|
|
require './spec/support/test_env'
|
2016-09-09 07:34:28 -04:00
|
|
|
|
|
|
|
class Gitlab::Seeder::CycleAnalytics
|
2016-09-14 10:10:31 -04:00
|
|
|
def initialize(project, perf: false)
|
2016-09-09 07:34:28 -04:00
|
|
|
@project = project
|
2016-09-20 05:36:54 -04:00
|
|
|
@user = User.order(:id).last
|
2016-09-14 10:10:31 -04:00
|
|
|
@issue_count = perf ? 1000 : 5
|
2016-09-09 07:34:28 -04:00
|
|
|
stub_git_pre_receive!
|
|
|
|
end
|
|
|
|
|
|
|
|
# The GitLab API needn't be running for the fixtures to be
|
|
|
|
# created. Since we're performing a number of git actions
|
|
|
|
# here (like creating a branch or committing a file), we need
|
|
|
|
# to disable the `pre_receive` hook in order to remove this
|
|
|
|
# dependency on the GitLab API.
|
|
|
|
def stub_git_pre_receive!
|
|
|
|
GitHooksService.class_eval do
|
|
|
|
def run_hook(name)
|
|
|
|
[true, '']
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-09-15 10:12:12 -04:00
|
|
|
def seed_metrics!
|
|
|
|
@issue_count.times do |index|
|
|
|
|
# Issue
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
title = "#{FFaker::Product.brand}-#{FFaker::Product.brand}-#{rand(1000)}"
|
|
|
|
issue = Issue.create(project: @project, title: title, author: @user)
|
|
|
|
issue_metrics = issue.metrics
|
|
|
|
|
|
|
|
# Milestones / Labels
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
if index.even?
|
|
|
|
issue_metrics.first_associated_with_milestone_at = rand(6..12).hours.from_now
|
|
|
|
else
|
|
|
|
issue_metrics.first_added_to_board_at = rand(6..12).hours.from_now
|
|
|
|
end
|
|
|
|
|
|
|
|
# Commit
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
issue_metrics.first_mentioned_in_commit_at = rand(6..12).hours.from_now
|
|
|
|
|
|
|
|
# MR
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
branch_name = "#{FFaker::Product.brand}-#{FFaker::Product.brand}-#{rand(1000)}"
|
|
|
|
@project.repository.add_branch(@user, branch_name, 'master')
|
|
|
|
merge_request = MergeRequest.create(target_project: @project, source_project: @project, source_branch: branch_name, target_branch: 'master', title: branch_name, author: @user)
|
|
|
|
merge_request_metrics = merge_request.metrics
|
|
|
|
|
|
|
|
# MR closing issues
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
MergeRequestsClosingIssues.create!(issue: issue, merge_request: merge_request)
|
|
|
|
|
|
|
|
# Merge
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
merge_request_metrics.merged_at = rand(6..12).hours.from_now
|
|
|
|
|
|
|
|
# Start build
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
merge_request_metrics.latest_build_started_at = rand(6..12).hours.from_now
|
|
|
|
|
|
|
|
# Finish build
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
merge_request_metrics.latest_build_finished_at = rand(6..12).hours.from_now
|
|
|
|
|
|
|
|
# Deploy to production
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
merge_request_metrics.first_deployed_to_production_at = rand(6..12).hours.from_now
|
|
|
|
|
|
|
|
issue_metrics.save!
|
|
|
|
merge_request_metrics.save!
|
|
|
|
|
|
|
|
print '.'
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2016-09-09 07:34:28 -04:00
|
|
|
def seed!
|
|
|
|
Sidekiq::Testing.inline! do
|
2016-09-15 10:12:12 -04:00
|
|
|
issues = create_issues
|
|
|
|
puts '.'
|
2016-09-09 07:34:28 -04:00
|
|
|
|
|
|
|
# Stage 1
|
|
|
|
Timecop.travel 5.days.from_now
|
|
|
|
add_milestones_and_list_labels(issues)
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
print '.'
|
2016-09-09 07:34:28 -04:00
|
|
|
|
|
|
|
# Stage 2
|
2016-09-14 10:10:31 -04:00
|
|
|
Timecop.travel 5.days.from_now
|
2016-09-09 07:34:28 -04:00
|
|
|
branches = mention_in_commits(issues)
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
print '.'
|
2016-09-09 07:34:28 -04:00
|
|
|
|
|
|
|
# Stage 3
|
2016-09-14 10:10:31 -04:00
|
|
|
Timecop.travel 5.days.from_now
|
2016-09-09 07:34:28 -04:00
|
|
|
merge_requests = create_merge_requests_closing_issues(issues, branches)
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
print '.'
|
2016-09-09 07:34:28 -04:00
|
|
|
|
|
|
|
# Stage 4
|
2016-09-14 10:10:31 -04:00
|
|
|
Timecop.travel 5.days.from_now
|
2016-09-09 07:34:28 -04:00
|
|
|
run_builds(merge_requests)
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
print '.'
|
2016-09-09 07:34:28 -04:00
|
|
|
|
|
|
|
# Stage 5
|
2016-09-14 10:10:31 -04:00
|
|
|
Timecop.travel 5.days.from_now
|
2016-09-09 07:34:28 -04:00
|
|
|
merge_merge_requests(merge_requests)
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
print '.'
|
2016-09-09 07:34:28 -04:00
|
|
|
|
|
|
|
# Stage 6 / 7
|
2016-09-14 10:10:31 -04:00
|
|
|
Timecop.travel 5.days.from_now
|
2016-09-09 07:34:28 -04:00
|
|
|
deploy_to_production(merge_requests)
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
print '.'
|
2016-09-09 07:34:28 -04:00
|
|
|
end
|
|
|
|
|
|
|
|
print '.'
|
|
|
|
end
|
|
|
|
|
|
|
|
private
|
|
|
|
|
2016-09-15 10:12:12 -04:00
|
|
|
def create_issues
|
2016-09-14 10:10:31 -04:00
|
|
|
Array.new(@issue_count) do
|
2016-09-09 07:34:28 -04:00
|
|
|
issue_params = {
|
|
|
|
title: "Cycle Analytics: #{FFaker::Lorem.sentence(6)}",
|
|
|
|
description: FFaker::Lorem.sentence,
|
|
|
|
state: 'opened',
|
|
|
|
assignee: @project.team.users.sample
|
|
|
|
}
|
|
|
|
|
|
|
|
Issues::CreateService.new(@project, @project.team.users.sample, issue_params).execute
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def add_milestones_and_list_labels(issues)
|
|
|
|
issues.shuffle.map.with_index do |issue, index|
|
|
|
|
Timecop.travel 12.hours.from_now
|
|
|
|
|
|
|
|
if index.even?
|
|
|
|
issue.update(milestone: @project.milestones.sample)
|
|
|
|
else
|
|
|
|
label_name = "#{FFaker::Product.brand}-#{FFaker::Product.brand}-#{rand(1000)}"
|
|
|
|
list_label = FactoryGirl.create(:label, title: label_name, project: issue.project)
|
|
|
|
FactoryGirl.create(:list, board: FactoryGirl.create(:board, project: issue.project), label: list_label)
|
|
|
|
issue.update(labels: [list_label])
|
|
|
|
end
|
|
|
|
|
|
|
|
issue
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def mention_in_commits(issues)
|
|
|
|
issues.map do |issue|
|
|
|
|
Timecop.travel 12.hours.from_now
|
|
|
|
|
|
|
|
branch_name = filename = "#{FFaker::Product.brand}-#{FFaker::Product.brand}-#{rand(1000)}"
|
|
|
|
|
|
|
|
issue.project.repository.add_branch(@user, branch_name, 'master')
|
|
|
|
|
|
|
|
options = {
|
|
|
|
committer: issue.project.repository.user_to_committer(@user),
|
|
|
|
author: issue.project.repository.user_to_committer(@user),
|
|
|
|
commit: { message: "Commit for ##{issue.iid}", branch: branch_name, update_ref: true },
|
|
|
|
file: { content: "content", path: filename, update: false }
|
|
|
|
}
|
|
|
|
|
|
|
|
commit_sha = Gitlab::Git::Blob.commit(issue.project.repository, options)
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
issue.project.repository.commit(commit_sha)
|
|
|
|
|
|
|
|
|
|
|
|
GitPushService.new(issue.project,
|
|
|
|
@user,
|
|
|
|
oldrev: issue.project.repository.commit("master").sha,
|
|
|
|
newrev: commit_sha,
|
|
|
|
ref: 'refs/heads/master').execute
|
2016-09-09 07:34:28 -04:00
|
|
|
|
|
|
|
branch_name
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def create_merge_requests_closing_issues(issues, branches)
|
|
|
|
issues.zip(branches).map do |issue, branch|
|
|
|
|
Timecop.travel 12.hours.from_now
|
|
|
|
|
|
|
|
opts = {
|
|
|
|
title: 'Cycle Analytics merge_request',
|
|
|
|
description: "Fixes #{issue.to_reference}",
|
|
|
|
source_branch: branch,
|
|
|
|
target_branch: 'master'
|
|
|
|
}
|
|
|
|
|
|
|
|
MergeRequests::CreateService.new(issue.project, @user, opts).execute
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def run_builds(merge_requests)
|
|
|
|
merge_requests.each do |merge_request|
|
|
|
|
Timecop.travel 12.hours.from_now
|
|
|
|
|
|
|
|
service = Ci::CreatePipelineService.new(merge_request.project,
|
|
|
|
@user,
|
|
|
|
ref: "refs/heads/#{merge_request.source_branch}")
|
|
|
|
pipeline = service.execute(ignore_skip_ci: true, save_on_errors: false)
|
|
|
|
|
|
|
|
pipeline.run!
|
|
|
|
Timecop.travel rand(1..6).hours.from_now
|
|
|
|
pipeline.succeed!
|
2016-11-18 04:50:47 -05:00
|
|
|
|
|
|
|
PipelineMetricsWorker.new.perform(pipeline.id)
|
2016-09-09 07:34:28 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def merge_merge_requests(merge_requests)
|
|
|
|
merge_requests.each do |merge_request|
|
|
|
|
Timecop.travel 12.hours.from_now
|
|
|
|
|
|
|
|
MergeRequests::MergeService.new(merge_request.project, @user).execute(merge_request)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
def deploy_to_production(merge_requests)
|
|
|
|
merge_requests.each do |merge_request|
|
|
|
|
Timecop.travel 12.hours.from_now
|
|
|
|
|
|
|
|
CreateDeploymentService.new(merge_request.project, @user, {
|
|
|
|
environment: 'production',
|
|
|
|
ref: 'master',
|
|
|
|
tag: false,
|
|
|
|
sha: @project.repository.commit('master').sha
|
|
|
|
}).execute
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
Gitlab::Seeder.quiet do
|
2016-09-14 10:10:31 -04:00
|
|
|
if ENV['SEED_CYCLE_ANALYTICS']
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
Project.all.each do |project|
|
|
|
|
seeder = Gitlab::Seeder::CycleAnalytics.new(project)
|
2016-09-14 10:10:31 -04:00
|
|
|
seeder.seed!
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
end
|
2016-09-14 10:10:31 -04:00
|
|
|
elsif ENV['CYCLE_ANALYTICS_PERF_TEST']
|
Improve performance of the cycle analytics page.
1. These changes bring down page load time for 100 issues from more than
a minute to about 1.5 seconds.
2. This entire commit is composed of these types of performance
enhancements:
- Cache relevant data in `IssueMetrics` wherever possible.
- Cache relevant data in `MergeRequestMetrics` wherever possible.
- Preload metrics
3. Given these improvements, we now only need to make 4 SQL calls:
- Load all issues
- Load all merge requests
- Load all metrics for the issues
- Load all metrics for the merge requests
4. A list of all the data points that are now being pre-calculated:
a. The first time an issue is mentioned in a commit
- In `GitPushService`, find all issues mentioned by the given commit
using `ReferenceExtractor`. Set the `first_mentioned_in_commit_at`
flag for each of them.
- There seems to be a (pre-existing) bug here - files (and
therefore commits) created using the Web CI don't have
cross-references created, and issues are not closed even when
the commit title is "Fixes #xx".
b. The first time a merge request is deployed to production
When a `Deployment` is created, find all merge requests that
were merged in before the deployment, and set the
`first_deployed_to_production_at` flag for each of them.
c. The start / end time for a merge request pipeline
Hook into the `Pipeline` state machine. When the `status` moves to
`running`, find the merge requests whose tip commit matches the
pipeline, and record the `latest_build_started_at` time for each
of them. When the `status` moves to `success`, record the
`latest_build_finished_at` time.
d. The merge requests that close an issue
- This was a big cause of the performance problems we were having
with Cycle Analytics. We need to use `ReferenceExtractor` to make
this calculation, which is slow when we have to run it on a large
number of merge requests.
- When a merge request is created, updated, or refreshed, find the
issues it closes, and create an instance of
`MergeRequestsClosingIssues`, which acts as a join model between
merge requests and issues.
- If a `MergeRequestsClosingIssues` instance links a merge request
and an issue, that issue closes that merge request.
5. The `Queries` module was changed into a class, so we can cache the
results of `issues` and `merge_requests_closing_issues` across
various cycle analytics stages.
6. The code added in this commit is untested. Tests will be added in the
next commit.
2016-09-15 04:59:36 -04:00
|
|
|
seeder = Gitlab::Seeder::CycleAnalytics.new(Project.order(:id).first, perf: true)
|
2016-09-09 07:34:28 -04:00
|
|
|
seeder.seed!
|
2016-09-15 10:12:12 -04:00
|
|
|
elsif ENV['CYCLE_ANALYTICS_POPULATE_METRICS_DIRECTLY']
|
|
|
|
seeder = Gitlab::Seeder::CycleAnalytics.new(Project.order(:id).first, perf: true)
|
|
|
|
seeder.seed_metrics!
|
2016-09-14 10:10:31 -04:00
|
|
|
else
|
|
|
|
puts "Not running the cycle analytics seed file. Use the `SEED_CYCLE_ANALYTICS` environment variable to enable it."
|
2016-09-09 07:34:28 -04:00
|
|
|
end
|
|
|
|
end
|