BigW Consortium Gitlab

Commit abfceb1e by Kamil Trzcinski

Cleanup changes

parent 4a5c2172
......@@ -744,21 +744,10 @@ class MergeRequest < ActiveRecord::Base
@pipeline ||= source_project.pipeline_for(source_branch, diff_head_sha)
end
def all_commits_sha
merge_request_diffs.map(&:commits).flatten.map(&:sha).sort.uniq
end
def latest_pipelines
@latest_pipelines ||=
if diff_head_sha && source_project
source_project.pipelines.order(id: :desc).where(sha: commits_sha, ref: source_branch)
end
end
def all_pipelines
@all_pipelines ||=
if diff_head_sha && source_project
source_project.pipelines.order(id: :desc).where(sha: all_commits_sha, ref: source_branch)
source_project.pipelines.order(id: :desc).where(sha: commits_sha, ref: source_branch)
end
end
......
# See http://doc.gitlab.com/ce/development/migration_style_guide.html
# for more information on how to write migrations for GitLab.
class AddEnvironmentTypeToEnvironments < ActiveRecord::Migration
include Gitlab::Database::MigrationHelpers
# Set this constant to true if this migration requires downtime.
DOWNTIME = false
# When a migration requires downtime you **must** uncomment the following
# constant and define a short and easy to understand explanation as to why the
# migration requires downtime.
# DOWNTIME_REASON = ''
# When using the methods "add_concurrent_index" or "add_column_with_default"
# you must disable the use of transactions as these methods can not run in an
# existing transaction. When using "add_concurrent_index" make sure that this
# method is the _only_ method called in the migration, any other changes
# should go in a separate migration. This ensures that upon failure _only_ the
# index creation fails and can be retried or reverted easily.
#
# To disable transactions uncomment the following line and remove these
# comments:
# disable_ddl_transaction!
def change
add_column :environments, :environment_type, :string
end
......
......@@ -577,9 +577,9 @@ The `deploy to production` job will be marked as doing deployment to
Introduced in GitLab 8.12.
`environment` can also represent a configuration hash with `name` and `url`.
These parameters can use any of defined CI variables (including predefined, secure variables and .gitlab-ci.yml variables).
These parameters can use any of the defined CI variables (including predefined, secure variables and `.gitlab-ci.yml` variables).
The common use case is to create a dynamic environments for branches and use them as review apps.
The common use case is to create dynamic environments for branches and use them as review apps.
---
......@@ -594,9 +594,10 @@ deploy as review app:
url: https://$CI_BUILD_REF_NAME.review.example.com/
```
The `deploy to production` job will be marked as doing deployment to
`production` environment.
The `deploy as review app` job will be marked as deployment to
dynamically created `review-apps/branch-name` environment.
This environment should be accessible under `https://branch-name.review.example.com/`.
### artifacts
......
......@@ -36,14 +36,11 @@ module Gitlab
end
def name
case @config.type
when String then @config
when Hash then @config[:name]
end
value[:name]
end
def url
@config[:url] if hash?
value[:url]
end
def value
......
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