Commit 47f007d6 authored by Kamil Trzcinski's avatar Kamil Trzcinski

Merge remote-tracking branch 'origin/master' into pipeline-hooks-without-slack

parents a391652f 283b2c0b
...@@ -59,7 +59,7 @@ module Ci ...@@ -59,7 +59,7 @@ module Ci
when: build.when, when: build.when,
user: user, user: user,
environment: build.environment, environment: build.environment,
status_event: 'queue' status_event: 'enqueue'
) )
MergeRequests::AddTodoWhenBuildFailsService.new(build.project, nil).close(new_build) MergeRequests::AddTodoWhenBuildFailsService.new(build.project, nil).close(new_build)
new_build new_build
...@@ -102,7 +102,7 @@ module Ci ...@@ -102,7 +102,7 @@ module Ci
def play(current_user = nil) def play(current_user = nil)
# Try to queue a current build # Try to queue a current build
if self.queue if self.enqueue
self.update(user: current_user) self.update(user: current_user)
self self
else else
......
...@@ -22,9 +22,9 @@ module Ci ...@@ -22,9 +22,9 @@ module Ci
delegate :stages, to: :statuses delegate :stages, to: :statuses
state_machine :status, initial: :created do state_machine :status, initial: :created do
event :queue do event :enqueue do
transition created: :pending transition created: :pending
transition any - [:created, :pending] => :running transition [:success, :failed, :canceled, :skipped] => :running
end end
event :run do event :run do
...@@ -230,18 +230,12 @@ module Ci ...@@ -230,18 +230,12 @@ module Ci
def build_updated def build_updated
case latest_builds_status case latest_builds_status
when 'pending' when 'pending' then enqueue
queue when 'running' then run
when 'running' when 'success' then succeed
run when 'failed' then drop
when 'success' when 'canceled' then cancel
succeed when 'skipped' then skip
when 'failed'
drop
when 'canceled'
cancel
when 'skipped'
skip
end end
end end
......
...@@ -26,7 +26,7 @@ class CommitStatus < ActiveRecord::Base ...@@ -26,7 +26,7 @@ class CommitStatus < ActiveRecord::Base
scope :ignored, -> { where(allow_failure: true, status: [:failed, :canceled]) } scope :ignored, -> { where(allow_failure: true, status: [:failed, :canceled]) }
state_machine :status do state_machine :status do
event :queue do event :enqueue do
transition [:created, :skipped] => :pending transition [:created, :skipped] => :pending
end end
......
class SpamReport < ActiveRecord::Base
belongs_to :user
validates :user, presence: true
end
...@@ -37,7 +37,7 @@ module Ci ...@@ -37,7 +37,7 @@ module Ci
return false unless Statuseable::COMPLETED_STATUSES.include?(current_status) return false unless Statuseable::COMPLETED_STATUSES.include?(current_status)
if valid_statuses_for_when(build.when).include?(current_status) if valid_statuses_for_when(build.when).include?(current_status)
build.queue build.enqueue
true true
else else
build.skip build.skip
......
...@@ -15,8 +15,8 @@ The process of solving performance problems is roughly as follows: ...@@ -15,8 +15,8 @@ The process of solving performance problems is roughly as follows:
3. Add your findings based on the measurement period (screenshots of graphs, 3. Add your findings based on the measurement period (screenshots of graphs,
timings, etc) to the issue mentioned in step 1. timings, etc) to the issue mentioned in step 1.
4. Solve the problem. 4. Solve the problem.
5. Create a merge request, assign the "performance" label and ping the right 5. Create a merge request, assign the "Performance" label and assign it to
people (e.g. [@yorickpeterse][yorickpeterse] and [@joshfng][joshfng]). [@yorickpeterse][yorickpeterse] for reviewing.
6. Once a change has been deployed make sure to _again_ measure for at least 24 6. Once a change has been deployed make sure to _again_ measure for at least 24
hours to see if your changes have any impact on the production environment. hours to see if your changes have any impact on the production environment.
7. Repeat until you're done. 7. Repeat until you're done.
...@@ -36,8 +36,8 @@ graphs/dashboards. ...@@ -36,8 +36,8 @@ graphs/dashboards.
GitLab provides two built-in tools to aid the process of improving performance: GitLab provides two built-in tools to aid the process of improving performance:
* [Sherlock](doc/development/profiling.md#sherlock) * [Sherlock](profiling.md#sherlock)
* [GitLab Performance Monitoring](doc/monitoring/performance/monitoring.md) * [GitLab Performance Monitoring](../monitoring/performance/monitoring.md)
GitLab employees can use GitLab.com's performance monitoring systems located at GitLab employees can use GitLab.com's performance monitoring systems located at
<http://performance.gitlab.net>, this requires you to log in using your <http://performance.gitlab.net>, this requires you to log in using your
...@@ -254,5 +254,4 @@ referencing an object directly may even slow code down. ...@@ -254,5 +254,4 @@ referencing an object directly may even slow code down.
[#15607]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15607 [#15607]: https://gitlab.com/gitlab-org/gitlab-ce/issues/15607
[yorickpeterse]: https://gitlab.com/u/yorickpeterse [yorickpeterse]: https://gitlab.com/u/yorickpeterse
[joshfng]: https://gitlab.com/u/joshfng
[anti-pattern]: https://en.wikipedia.org/wiki/Anti-pattern [anti-pattern]: https://en.wikipedia.org/wiki/Anti-pattern
...@@ -887,8 +887,10 @@ describe Ci::Build, models: true do ...@@ -887,8 +887,10 @@ describe Ci::Build, models: true do
is_expected.to eq(build) is_expected.to eq(build)
end end
context 'for success build' do context 'for successful build' do
before { build.queue } before do
build.update(status: 'success')
end
it 'creates a new build' do it 'creates a new build' do
is_expected.to be_pending is_expected.to be_pending
......
...@@ -145,7 +145,7 @@ describe Ci::Pipeline, models: true do ...@@ -145,7 +145,7 @@ describe Ci::Pipeline, models: true do
expect(pipeline.reload.started_at).not_to be_nil expect(pipeline.reload.started_at).not_to be_nil
end end
it 'do not update on transitioning to success' do it 'does not update on transitioning to success' do
build.success build.success
expect(pipeline.reload.started_at).to be_nil expect(pipeline.reload.started_at).to be_nil
...@@ -159,7 +159,7 @@ describe Ci::Pipeline, models: true do ...@@ -159,7 +159,7 @@ describe Ci::Pipeline, models: true do
expect(pipeline.reload.finished_at).not_to be_nil expect(pipeline.reload.finished_at).not_to be_nil
end end
it 'do not update on transitioning to running' do it 'does not update on transitioning to running' do
build.run build.run
expect(pipeline.reload.finished_at).to be_nil expect(pipeline.reload.finished_at).to be_nil
...@@ -259,14 +259,16 @@ describe Ci::Pipeline, models: true do ...@@ -259,14 +259,16 @@ describe Ci::Pipeline, models: true do
subject { pipeline.reload.status } subject { pipeline.reload.status }
context 'on queuing' do context 'on queuing' do
before { build.queue } before do
build.enqueue
end
it { is_expected.to eq('pending') } it { is_expected.to eq('pending') }
end end
context 'on run' do context 'on run' do
before do before do
build.queue build.enqueue
build.run build.run
end end
...@@ -296,6 +298,19 @@ describe Ci::Pipeline, models: true do ...@@ -296,6 +298,19 @@ describe Ci::Pipeline, models: true do
it { is_expected.to eq('canceled') } it { is_expected.to eq('canceled') }
end end
context 'on failure and build retry' do
before do
build.drop
Ci::Build.retry(build)
end
# We are changing a state: created > failed > running
# Instead of: created > failed > pending
# Since the pipeline already run, so it should not be pending anymore
it { is_expected.to eq('running') }
end
end end
describe '#execute_hooks' do describe '#execute_hooks' do
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment