gitlab-org--gitlab-foss/app/services/ci/create_trigger_request_serv...

module Ci
  class CreateTriggerRequestService
    def execute(project, trigger, ref, variables = nil)
      trigger_request = trigger.trigger_requests.create(variables: variables)

      pipeline = Ci::CreatePipelineService.new(project, trigger.owner, ref: ref).
        execute(ignore_skip_ci: true, trigger_request: trigger_request)
      if pipeline.persisted?
        trigger_request
      end
    end
  end
end
Groundwork for merging CI into CE 2015-08-26 01:42:46 +00:00			`module Ci`
			`class CreateTriggerRequestService`
			`def execute(project, trigger, ref, variables = nil)`
Pre-create all builds for Pipeline when a trigger is received This change simplifies a Pipeline processing by introducing a special new status: created. This status is used for all builds that are created for a pipeline. We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped). This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled. This also allows us to visualise a full pipeline (with created builds). This also removes an after_touch used for updating a pipeline state parameters. Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved. 2016-08-11 13:22:35 +00:00			`trigger_request = trigger.trigger_requests.create(variables: variables)`
Groundwork for merging CI into CE 2015-08-26 01:42:46 +00:00
Make triggers to be user aware 2017-03-05 17:23:42 +00:00			`pipeline = Ci::CreatePipelineService.new(project, trigger.owner, ref: ref).`
Pre-create all builds for Pipeline when a trigger is received This change simplifies a Pipeline processing by introducing a special new status: created. This status is used for all builds that are created for a pipeline. We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped). This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled. This also allows us to visualise a full pipeline (with created builds). This also removes an after_touch used for updating a pipeline state parameters. Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved. 2016-08-11 13:22:35 +00:00			`execute(ignore_skip_ci: true, trigger_request: trigger_request)`
			`if pipeline.persisted?`
Groundwork for merging CI into CE 2015-08-26 01:42:46 +00:00			`trigger_request`
			`end`
			`end`
			`end`
			`end`