Commit c95cca9d authored by Dmitriy Zaporozhets's avatar Dmitriy Zaporozhets

Merge branch '6-8-ce-to-ee' into 'master'

Upstream 6.8 CE to EE
parents 48fa4ec0 55e46ad5
......@@ -36,3 +36,4 @@ doc/code/*
public/uploads.*
public/assets/
.envrc
dump.rdb
......@@ -4,10 +4,14 @@ env:
- TRAVIS=true
matrix:
- TASK=spinach DB=mysql
- TASK=spec DB=mysql
- TASK=spec:api DB=mysql
- TASK=spec:feature DB=mysql
- TASK=spec:other DB=mysql
- TASK=jasmine:ci DB=mysql
- TASK=spinach DB=postgresql
- TASK=spec DB=postgresql
- TASK=spec:api DB=postgresql
- TASK=spec:feature DB=postgresql
- TASK=spec:other DB=postgresql
- TASK=jasmine:ci DB=postgresql
before_install:
- sudo apt-get install libicu-dev -y
......
......@@ -14,6 +14,9 @@ v 6.8.0
- Fix faulty namespace names that caused 500 on user creation
- Option to disable standard login
- Clean old created archives from repository downloads directory
- Fix download link for huge MR diffs
- Expose event and mergerequest timestamps in API
- Fix emails on push service when only one commit is pushed
v 6.7.3
- Fix the merge notification email not being sent (Pierre de La Morinerie)
......
......@@ -29,6 +29,8 @@ If something is wrong but it is not a regression compared to older versions of G
When submitting an issue please conform to the issue submission guidelines listed below.
Not all issues will be addressed and your issue is more likely to be addressed if you submit a merge request which partially or fully addresses the issue.
Issues can be filed either at [gitlab.com](https://gitlab.com/gitlab-org/gitlab-ce/issues) or [github.com](https://github.com/gitlabhq/gitlabhq/issues).
Do not use the issue tracker for feature requests.
We have a specific [feature request forum](http://feedback.gitlab.com) for this purpose.
Please keep feature requests as small and simple as possible, complex ones might be edited to make them small and simple.
......@@ -55,6 +57,8 @@ Please send a merge request with a tested solution or a merge request with a fai
We welcome merge requests with fixes and improvements to GitLab code, tests, and/or documentation. The features we would really like a merge request for are listed with the [status 'accepting merge requests' on our feature request forum](http://feedback.gitlab.com/forums/176466-general/status/796455) but other improvements are also welcome. If you want to add a new feature that is not marked it is best to first create a feedback issue (if there isn't one already) and leave a comment asking for it to be marked accepting merge requests. Please include screenshots or wireframes if the feature will also change the UI.
Merge requests can be filed either at [gitlab.com](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests) or [github.com](https://github.com/gitlabhq/gitlabhq/pulls).
### Merge request guidelines
If you can, please submit a merge request with the fix or improvements including tests. If you don't know how to fix the issue but can write a test that exposes the issue we will accept that as well. In general bug fixes that include a regression test are merged quickly while new features without proper tests are least likely to receive timely feedback. The workflow to make a merge request is as follows:
......@@ -102,8 +106,10 @@ For examples of feedback on merge requests please look at already [closed merge
1. It conforms to the following style guides
## Style guides
1. [Ruby style guide](https://github.com/bbatsov/ruby-style-guide)
1. [Rails style guide](https://github.com/bbatsov/rails-style-guide)
1. [CoffeeScript style guide](https://github.com/polarmobile/coffeescript-style-guide)
1. [Shell command guidelines](doc/development/shell_commands.md)
1. [Ruby](https://github.com/bbatsov/ruby-style-guide)
2. [Rails](https://github.com/bbatsov/rails-style-guide)
3. [Formatting](https://github.com/thoughtbot/guides/tree/master/style#formatting)
4. [Naming](https://github.com/thoughtbot/guides/tree/master/style#naming)
8. [Testing](https://github.com/thoughtbot/guides/tree/master/style#testing)
7. [CoffeeScript](https://github.com/thoughtbot/guides/tree/master/style#coffeescript)
9. [Shell commands](doc/development/shell_commands.md)
......@@ -132,7 +132,7 @@ gem "gitlab-flowdock-git-hook", "~> 0.4.2"
gem "gemnasium-gitlab-service", "~> 0.2"
# Slack integration
gem "slack-notifier", "~> 0.2.0"
gem "slack-notifier", "~> 0.3.2"
# d3
gem "d3_rails", "~> 3.1.4"
......
......@@ -462,7 +462,7 @@ GEM
rack-protection (~> 1.4)
tilt (~> 1.3, >= 1.3.4)
six (0.2.0)
slack-notifier (0.2.0)
slack-notifier (0.3.2)
slim (2.0.2)
temple (~> 0.6.6)
tilt (>= 1.3.3, < 2.1)
......@@ -645,7 +645,7 @@ DEPENDENCIES
simplecov
sinatra
six
slack-notifier (~> 0.2.0)
slack-notifier (~> 0.3.2)
slim
spinach-rails
spring (= 1.1.1)
......
......@@ -100,3 +100,10 @@ It's been at least 2 weeks (and a new release) since we heard from you. I'm clos
This merge request has been closed because a request for more information has not been reacted to for more than 2 weeks. If you respond and conform to the merge request guidelines in our \[contributing guidelines\]\(https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#pull-requests) we will reopen this merge request.
### Accepting merge requests
Is there a request on [the feature request forum](http://feedback.gitlab.com/forums/176466-general) that is similar to this?
If so, can you make a comment with a link to it?
Please be aware that new functionality that is not marked [accepting merge/pull requests](http://feedback.gitlab.com/forums/176466-general/status/796455) on the forum might not make it into GitLab.
You might be asked to make changes and even after implementing them your feature might still be declined.
If you want to reduce the chance of this happening please have a discussion in the forum first.
......@@ -9,10 +9,14 @@
* Manage git repositories with fine grained access controls that keep your code secure
* Perform code reviews and enhance collaboration with merge requests
* Each project can also have an issue tracker and a wiki
* Used by more than 50,000 organizations, GitLab is the most popular solution to manage git repositories on-premises
* Used by more than 100,000 organizations, GitLab is the most popular solution to manage git repositories on-premises
* Completely free and open source (MIT Expat license)
* Powered by Ruby on Rails
### Canonical source
* The source of GitLab Communinity Edition is [hosted on GitLab Cloud](https://gitlab.com/gitlab-org/gitlab-ce/) and there are mirrors to make [contributing](CONTRIBUTING.md) as easy as possible.
### Code status
* [![build status](https://ci.gitlab.org/projects/1/status.png?ref=master)](https://ci.gitlab.org/projects/1?ref=master) on ci.gitlab.org (master branch)
......@@ -81,8 +85,12 @@ or by directly calling the script
sudo /etc/init.d/gitlab start
Please login with root / 5iveL!fe
### Run in development mode
Consider setting up the development environment with [the cookbook](https://gitlab.com/gitlab-org/cookbook-gitlab/blob/master/README.md#installation).
Copy the example development unicorn configuration file
cp config/unicorn.rb.example.development config/unicorn.rb
......@@ -96,6 +104,8 @@ or start each component separately
bundle exec rails s
script/background_jobs start
And surf to [localhost:3000](http://localhost:3000/) and login with root / 5iveL!fe
### Run the tests
* Run all tests
......
6.8.0.pre-ee
<<<<<<< HEAD
6.8.0.rc1-ee
......@@ -26,9 +26,6 @@
float: left;
}
.commit-btn {
@extend .save-btn;
}
.message {
display: inline-block;
margin: 5px 8px 0 8px;
......
......@@ -54,7 +54,6 @@ ul.notes {
.diff-file,
.discussion-hidden,
.notes {
@extend .borders;
background-color: #F9F9F9;
}
.diff-file .notes {
......
......@@ -108,8 +108,6 @@ class Projects::MergeRequestsController < Projects::ApplicationController
@merge_request.check_if_can_be_merged
end
render json: {merge_status: @merge_request.merge_status_name}
rescue Gitlab::SatelliteNotExistError
render json: {merge_status: :no_satellite}
end
def automerge
......
......@@ -8,7 +8,8 @@ class Projects::TagsController < Projects::ApplicationController
before_filter :authorize_admin_project!, only: [:destroy]
def index
@tags = Kaminari.paginate_array(@repository.tags.reverse).page(params[:page]).per(30)
sorted = VersionSorter.rsort(@repository.tag_names)
@tags = Kaminari.paginate_array(sorted).page(params[:page]).per(30)
end
def create
......
......@@ -7,7 +7,7 @@ class Projects::WikisController < Projects::ApplicationController
before_filter :load_project_wiki
def pages
@wiki_pages = @project_wiki.pages
@wiki_pages = Kaminari.paginate_array(@project_wiki.pages).page(params[:page]).per(30)
end
def show
......
......@@ -12,7 +12,7 @@ module LabelsHelper
def label_css_class(name)
klass = Gitlab::IssuesLabels
case name
case name.downcase
when *klass.warning_labels
'label-warning'
when *klass.neutral_labels
......
......@@ -5,7 +5,7 @@ module ProjectsHelper
def link_to_project project
link_to project do
title = content_tag(:span, project.name, class: 'projet-name')
title = content_tag(:span, project.name, class: 'project-name')
if project.namespace
namespace = content_tag(:span, "#{project.namespace.human_name} / ", class: 'namespace-name')
......
......@@ -26,7 +26,7 @@ module Emails
if @commits.length > 1
@target_url = project_compare_url(@project, from: @commits.first, to: @commits.last)
else
@target_url = project_commit_url(@project, @compare.commit)
@target_url = project_commit_url(@project, @commits.first)
end
mail(from: sender(author_id),
......
......@@ -47,7 +47,11 @@ class WikiPage
# The formatted title of this page.
def title
@attributes[:title] || ""
if @attributes[:title]
@attributes[:title].gsub(/-+/, ' ')
else
""
end
end
# Sets the title of this page.
......@@ -57,12 +61,16 @@ class WikiPage
# The raw content of this page.
def content
@attributes[:content]
@attributes[:content] ||= if @page
@page.raw_data
end
end
# The processed/formatted content of this page.
def formatted_content
@attributes[:formatted_content]
@attributes[:formatted_content] ||= if @page
@page.formatted_data
end
end
# The markup format for the page.
......@@ -163,8 +171,6 @@ class WikiPage
def set_attributes
attributes[:slug] = @page.escaped_url_path
attributes[:title] = @page.title
attributes[:content] = @page.raw_data
attributes[:formatted_content] = @page.formatted_data
attributes[:format] = @page.format
end
......
......@@ -93,6 +93,10 @@
Milestones
%span.light.pull-right
= Milestone.count
%p
Monthly active users
%span.light.pull-right
= User.where("current_sign_in_at > ?", 30.days.ago).count
.col-md-4
%h4
Features
......
......@@ -13,7 +13,7 @@
%br
Each project can also have an issue tracker and a wiki.
%br
Used by more than 50,000 organizations, GitLab is the most popular solution to manage git repositories on-premises.
Used by more than 100,000 organizations, GitLab is the most popular solution to manage git repositories on-premises.
%br
Read more about GitLab at #{link_to "www.gitlab.com", "https://www.gitlab.com/", target: "_blank"}.
......
......@@ -3,4 +3,4 @@
.help_body
= preserve do
= markdown File.read(Rails.root.join("doc", "ssh", "ssh.md"))
= markdown File.read(Rails.root.join("doc", "ssh", "ssh.md")).gsub("$your_email", current_user.email)
......@@ -21,6 +21,6 @@
\—
%br
- if @project
You're receiving this notification because you are a member of the #{link_to @project.name_with_namespace, project_url(@project)} project team.
You're receiving this notification because you are a member of the #{link_to_unless @target_url, @project.name_with_namespace, project_url(@project)} project team.
- if @target_url
#{link_to "View it on GitLab", @target_url}
......@@ -25,7 +25,7 @@
- unless empty_repo
.col-md-4
.project-home-links
= link_to pluralize(@repository.round_commit_count, 'commit'), project_commits_path(@project, @ref || @repository.root_ref)
= link_to pluralize(@repository.branch_names.count, 'branch'), project_branches_path(@project)
= link_to pluralize(@repository.tag_names.count, 'tag'), project_tags_path(@project)
= link_to pluralize(number_with_delimiter(@repository.commit_count), 'commit'), project_commits_path(@project, @ref || @repository.root_ref)
= link_to pluralize(number_with_delimiter(@repository.branch_names.count), 'branch'), project_branches_path(@project)
= link_to pluralize(number_with_delimiter(@repository.tag_names.count), 'tag'), project_tags_path(@project)
%span.light.prepend-left-20= repository_size
......@@ -13,11 +13,11 @@
%br
.form-group
= f.label :title, class: 'control-label' do
%strong= "Subject *"
%strong= 'Title *'
.col-sm-10
= f.text_field :title, maxlength: 255, class: "form-control js-gfm-input", autofocus: true, required: true
.form-group
= f.label :description, "Details", class: 'control-label'
= f.label :description, 'Description', class: 'control-label'
.col-sm-10
= f.text_area :description, class: "form-control js-gfm-input", rows: 14
%p.hint Issues are parsed with #{link_to "GitLab Flavored Markdown", help_markdown_path, target: '_blank'}.
......
......@@ -54,7 +54,7 @@
.clearfix
.issues_bulk_update.hide
= form_tag bulk_update_project_issues_path(@project), method: :post do
= select_tag('update[status]', options_for_select(['Open', 'Closed']), prompt: "Status")
= select_tag('update[status]', options_for_select([['Open', 'open'], ['Closed', 'closed']]), prompt: "Status")
= project_users_select_tag('update[assignee_id]', placeholder: 'Assignee')
= select_tag('update[milestone_id]', bulk_update_milestone_options, prompt: "Milestone")
= hidden_field_tag 'update[issues_ids]', []
......
......@@ -8,5 +8,5 @@
Changes view for this comparison is extremely large.
%p
You can
= link_to "download it", project_merge_request_path(@merge_request.source_project, @merge_request, format: :diff), class: "vlink"
= link_to "download it", project_merge_request_path(@merge_request.target_project, @merge_request, format: :diff), class: "vlink"
instead.
......@@ -7,13 +7,13 @@
New tag
%p
Tags give ability to mark specific points in history as being important
Tags give the ability to mark specific points in history as being important
%hr
- unless @tags.empty?
%ul.bordered-list
- @tags.each do |tag|
= render 'tag', tag: tag
= render 'tag', tag: @repository.find_tag(tag)
= paginate @tags, theme: 'gitlab'
......
......@@ -3,7 +3,7 @@
= render 'main_links'
%h3.page-title
Editing -
%span.light #{@page.title.titleize}
%span.light #{@page.title}
%hr
= render 'form'
......
= render 'nav'
%h3.page-title
%span.light History for
= link_to @page.title.titleize, project_wiki_path(@project, @page)
= link_to @page.title, project_wiki_path(@project, @page)
%table.table
%thead
......
......@@ -5,7 +5,8 @@
- @wiki_pages.each do |wiki_page|
%li
%h4
= link_to wiki_page.title.titleize, project_wiki_path(@project, wiki_page)
= link_to wiki_page.title, project_wiki_path(@project, wiki_page)
%small (#{wiki_page.format})
.pull-right
%small Last edited #{time_ago_with_tooltip(wiki_page.commit.created_at)}
= paginate @wiki_pages, theme: 'gitlab'
= render 'nav'
%h3.page-title
= @page.title.titleize
= @page.title
= render 'main_links'
- if @page.historical?
.warning_message
......
......@@ -20,7 +20,7 @@ production: &base
https: false
# Uncomment and customize the last line to run in a non-root path
# WARNING: We recommend creating a FQDN to host GitLab in a root path instead of this.
# WARNING: We recommend creating a FQDN to host GitLab in a root path instead of this.
# Note that four settings need to be changed for this to work.
# 1) In your application.rb file: config.relative_url_root = "/gitlab"
# 2) In your gitlab.yml file: relative_url_root: /gitlab
......@@ -69,7 +69,7 @@ production: &base
# If a commit message matches this regular expression, all issues referenced from the matched text will be closed.
# This happens when the commit is pushed or merged into the default branch of a project.
# When not specified the default issue_closing_pattern as specified below will be used.
# issue_closing_pattern: '([Cc]lose[sd]|[Ff]ixe[sd]) +#\d+'
# issue_closing_pattern: '([Cc]lose[sd]|[Ff]ixe[sd]) #(\d+)'
## Default project features settings
default_projects_features:
......@@ -107,7 +107,7 @@ production: &base
# ## :project_id - GitLab project identifier
# ## :issues_tracker_id - Project Name or Id in external issue tracker
# new_issue_url: "http://redmine.sample/projects/:issues_tracker_id/issues/new"
#
#
# jira:
# title: "Atlassian Jira"
# project_url: "http://jira.sample/issues/?jql=project=:issues_tracker_id"
......@@ -181,9 +181,10 @@ production: &base
## Auth providers
# Uncomment the following lines and fill in the data of the auth provider you want to use
# If your favorite auth provider is not listed you can use others:
# see https://github.com/gitlabhq/gitlab-public-wiki/wiki/Working-custom-omniauth-provider-configurations
# see https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations
# The 'app_id' and 'app_secret' parameters are always passed as the first two
# arguments, followed by optional 'args' which can be either a hash or an array.
# Documentation for this is available at http://doc.gitlab.com/ce/integration/omniauth.html
providers:
# - { name: 'google_oauth2', app_id: 'YOUR APP ID',
# app_secret: 'YOUR APP SECRET',
......
......@@ -90,7 +90,7 @@ Settings.gitlab['signup_enabled'] ||= false
Settings.gitlab['signin_enabled'] ||= true if Settings.gitlab['signin_enabled'].nil?
Settings.gitlab['restricted_visibility_levels'] = Settings.send(:verify_constant_array, Gitlab::VisibilityLevel, Settings.gitlab['restricted_visibility_levels'], [])
Settings.gitlab['username_changing_enabled'] = true if Settings.gitlab['username_changing_enabled'].nil?
Settings.gitlab['issue_closing_pattern'] = '([Cc]loses|[Ff]ixes) #(\d+)' if Settings.gitlab['issue_closing_pattern'].nil?
Settings.gitlab['issue_closing_pattern'] = '([Cc]lose[sd]|[Ff]ixe[sd]) #(\d+)' if Settings.gitlab['issue_closing_pattern'].nil?
Settings.gitlab['default_projects_features'] ||= {}
Settings.gitlab.default_projects_features['issues'] = true if Settings.gitlab.default_projects_features['issues'].nil?
Settings.gitlab.default_projects_features['merge_requests'] = true if Settings.gitlab.default_projects_features['merge_requests'].nil?
......
......@@ -345,5 +345,7 @@ Gitlab::Application.routes.draw do
end
end
get ':id' => "groups#show", constraints: {id: /(?:[^.]|\.(?!atom$))+/, format: /atom/}
root to: "dashboard#show"
end
class ChangeStateToAllowEmptyMergeRequestDiffs < ActiveRecord::Migration
def up
change_column :merge_request_diffs, :state, :string, null: true,
default: nil
end
def down
change_column :merge_request_diffs, :state, :string, null: false,
default: 'collected'
end
end
......@@ -11,7 +11,7 @@
#
# It's strongly recommended that you check this file into your version control system.
ActiveRecord::Schema.define(version: 20140414093351) do
ActiveRecord::Schema.define(version: 20140414131055) do
# These are extensions that must be enabled in order to support this database
enable_extension "plpgsql"
......@@ -128,10 +128,10 @@ ActiveRecord::Schema.define(version: 20140414093351) do
add_index "keys", ["user_id"], name: "index_keys_on_user_id", using: :btree
create_table "merge_request_diffs", force: true do |t|
t.string "state", default: "collected", null: false
t.string "state"
t.text "st_commits"
t.text "st_diffs"
t.integer "merge_request_id", null: false
t.integer "merge_request_id", null: false
t.datetime "created_at"
t.datetime "updated_at"
end
......@@ -186,9 +186,9 @@ ActiveRecord::Schema.define(version: 20140414093351) do
t.datetime "updated_at"
t.string "type"
t.string "description", default: "", null: false
t.string "avatar"
t.string "ldap_cn"
t.integer "ldap_access"
t.string "avatar"
end
add_index "namespaces", ["name"], name: "index_namespaces_on_name", using: :btree
......
......@@ -6,7 +6,7 @@
+ [Public access](public_access/public_access.md) Learn how you can allow public and internal access to a project.
+ [SSH](ssh/README.md) Setup your ssh keys and deploy keys for secure access to your projects.
+ [Web hooks](web_hooks/web_hooks.md) Let GitLab notify you when new code has been pushed to your project.
+ [Workflow](workflow/workflow.md) Learn how to use Git and GitLab together.
+ [Workflow](workflow/README.md) Learn how to use Git and GitLab together.
**Administrator documentation**
......
# GitLab API
## End-points
## Resources
+ [Users](users.md)
+ [Session](session.md)
......
## List merge requests
Get all merge requests for this project. This function takes pagination parameters
`page` and `per_page` to restrict the list of merge requests.
Get all merge requests for this project.
The `state` parameter can be used to get only merge requests with a
given state (`opened`, `closed`, or `merged`) or all of them (`all`).
The pagination parameters `page` and `per_page` can be used to restrict the
list of merge requests.
```
GET /projects/:id/merge_requests
GET /projects/:id/merge_requests?state=opened
GET /projects/:id/merge_requests?state=all
```
Parameters:
+ `id` (required) - The ID of a project
+ `state` (optional) - Return `all` requests or just those that are `merged`, `opened` or `closed`
```json
[
......
......@@ -173,13 +173,13 @@ We recommend using a PostgreSQL database. For MySQL check [MySQL setup guide](da
## Clone the Source
# Clone GitLab repository
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-7-stable-ee gitlab
sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-8-stable-ee gitlab
# Go to gitlab dir
cd /home/git/gitlab
**Note:**
You can change `6-7-stable-ee` to `master` if you want the *bleeding edge* version, but never install master on a production server!
You can change `6-8-stable-ee` to `master` if you want the *bleeding edge* version, but never install master on a production server!
## Configure it
......@@ -232,20 +232,21 @@ Make sure to edit both `gitlab.yml` and `unicorn.rb` to match your setup.
## Configure GitLab DB settings
# PostgreSQL
# PostgreSQL only:
sudo -u git cp config/database.yml.postgresql config/database.yml
# Make sure to update username/password in config/database.yml.
# MySQL only:
sudo -u git cp config/database.yml.mysql config/database.yml
# MySQL and remote PostgreSQL only:
# Update username/password in config/database.yml.
# You only need to adapt the production settings (first part).
# If you followed the database guide then please do as follows:
# Change 'secure password' with the value you have given to $password
# You can keep the double quotes around the password
sudo -u git -H editor config/database.yml
or
# Mysql
sudo -u git cp config/database.yml.mysql config/database.yml
# PostgreSQL and MySQL:
# Make config/database.yml readable to git only
sudo -u git -H chmod o-rwx config/database.yml
......@@ -372,7 +373,7 @@ nobody can access your GitLab by using this login information later on.
## Additional markup styles
Apart from the always supported markdown style there are other rich text files that GitLab can display.
But you might have to install a depency to do so.
But you might have to install a dependency to do so.
Please see the [github-markup gem readme](https://github.com/gitlabhq/markup#markups) for more information.
For example, reStructuredText markup language support requires python-docutils:
......@@ -420,9 +421,9 @@ These steps are fairly general and you will need to figure out the exact details
* Stop GitLab
`sudo service gitlab stop`
* Add provider specific configuration options to your `config/gitlab.yml` (you can use the [auth providers section of the example config](https://gitlab.com/gitlab-org/gitlab-ce/blob/masterconfig/gitlab.yml.example) as a reference)
* Add provider specific configuration options to your `config/gitlab.yml` (you can use the [auth providers section of the example config](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/gitlab.yml.example) as a reference)
* Add the gem to your [Gemfile](https://gitlab.com/gitlab-org/gitlab-ce/blob/masterGemfile)
* Add the gem to your [Gemfile](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile)
`gem "omniauth-your-auth-provider"`
* If you're using MySQL, install the new Omniauth provider gem by running the following command:
`sudo -u git -H bundle install --without development test postgres --path vendor/bundle --no-deployment`
......
......@@ -43,18 +43,24 @@ We love [JRuby](http://jruby.org/) and [Rubinius](http://rubini.us/)) but GitLab
## CPU
- 1 core works for under 100 users but the responsiveness might suffer
- **2 cores** is the **recommended** number of cores and supports up to 100 users
- 4 cores supports up to 1,000 users
- 8 cores supports up to 10,000 users
- 1 core works supports up to 100 users but the application will not be responsive
- **2 cores** is the **recommended** number of cores and supports up to 500 users
- 4 cores supports up to 2,000 users
- 8 cores supports up to 5,000 users
- 16 cores supports up to 10,0000 users
- 32 cores supports up to 20,0000 users
- 64 cores supports up to 40,0000 users
## Memory
- 512MB is too little memory, GitLab will be very slow and you will need 250MB of swap
- 768MB is the minimal memory size but we advise against this
- 512MB is the abolute minimum, you need 256MB of swap, you can configure only one slow unicorn worker, only ssh access will work, we do not recommend this
- 1GB supports up to 100 users (with individual repositories under 250MB, otherwise git memory usage necessitates using swap space)
- **2GB** is the **recommended** memory size and supports up to 1,000 users
- 4GB supports up to 10,000 users
- **2GB** is the **recommended** memory size and supports up to 500 users
- 4GB supports up to 2,000 users
- 8GB supports up to 5,000 users
- 16GB supports up to 10,000 users
- 32GB supports up to 20,000 users
- 64GB supports up to 40,000 users
## Storage
......
+ [External issue tracker](external-issue-tracker.md)
+ [LDAP](ldap.md)
+ [oAuth](oauth.md) Login with Twitter, GitHub, etc.
\ No newline at end of file
# GitLab Integration
GitLab integrates with multiple third-party services to allow external issue trackers and external authentication.
See the documentation below for details on how to configure these services.
+ [External issue tracker](external-issue-tracker.md) Redmine, JIRA, etc.
+ [LDAP](ldap.md) Set up sign in via LDAP
+ [OmniAuth](omniauth.md) Sign in via Twitter, GitHub, and Google via OAuth.
# GitHub OAuth2 OmniAuth Provider
To enable the GitHub OmniAuth provider you must register your application with GitHub. GitHub will generate a client ID and secret key for you to use.
1. Sign in to GitHub.
2. Navigate to your individual user settings or an organization's settings, depending on how you want the application registered. It does not matter if the application is registered as an individual or an organization - that is entirely up to you.
3. Select "Applications" in the left menu.
4. Select "Register new application".
5. Provide the required details.
* Application name: This can be anything. Consider something like "\<Organization\>'s GitLab" or "\<Your Name\>'s GitLab" or something else descriptive.
* Homepage URL: The URL to your GitLab installation. 'https://gitlab.company.com'
* Application description: Fill this in if you wish.
* Authorization callback URL: 'https://gitlab.company.com/users/auth/github/callback'
6. Select "Register application".
7. You should now see a Client ID and Client Secret near the top right of the page (see screenshot). Keep this page open as you continue configuration. ![GitHub app](github_app.png)
8. On your GitLab server, open the configuration file.
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
9. Find the section dealing with OmniAuth. See [Initial OmniAuth Configuration](README.md#initial-omniauth-configuration) for more details.
10. Under `providers:` uncomment (or add) lines that look like the following:
```
- { name: 'github', app_id: 'YOUR APP ID',
app_secret: 'YOUR APP SECRET',
args: { scope: 'user:email' } }
```
11. Change 'YOUR APP ID' to the client ID from the GitHub application page from step 7.
12. Change 'YOUR APP SECRET' to the client secret from the GitHub application page from step 7.
13. Save the configuration file.
14. Restart GitLab for the changes to take effect.
On the sign in page there should now be a GitHub icon below the regular sign in form. Click the icon to begin the authentication process. GitHub will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in.
# Google OAuth2 OmniAuth Provider
To enable the Google OAuth2 OmniAuth provider you must register your application with Google. Google will generate a client ID and secret key for you to use.
1. Sign in to the [Google Developers Console](https://console.developers.google.com/) with the Google account you want to use to register GitLab.
2. Select "Create Project".
3. Provide the project information
* Project name: 'GitLab' works just fine here.
* Project ID: Must be unique to all Google Developer registered applications. Google provides a randomly generated Project ID by default. You can use the randomly generated ID or choose a new one.
4. Refresh the page. You should now see your new project in the list. Click on the project.
5. Select "APIs & auth" in the left menu.
6. Select "Credentials" in the submenu.
7. Select "Create New Client ID".
8. Fill in the required information
* Application type: "Web Application"
* Authorized JavaScript origins: This isn't really used by GitLab but go ahead and put 'https://gitlab.example.com' here.
* Authorized redirect URI: 'https://gitlab.example.com/users/auth/google_oauth2/callback'
9. Under the heading "Client ID for web application" you should see a Client ID and Client secret (see screenshot). Keep this page open as you continue configuration. ![Google app](google_app.png)
10. On your GitLab server, open the configuration file.
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
11. Find the section dealing with OmniAuth. See [Initial OmniAuth Configuration](README.md#initial-omniauth-configuration) for more details.
12. Under `providers:` uncomment (or add) lines that look like the following:
```
- { name: 'google_oauth2', app_id: 'YOUR APP ID',
app_secret: 'YOUR APP SECRET',
args: { access_type: 'offline', approval_prompt: '' } }
```
13. Change 'YOUR APP ID' to the client ID from the GitHub application page from step 7.
14. Change 'YOUR APP SECRET' to the client secret from the GitHub application page from step 7.
15. Save the configuration file.
16. Restart GitLab for the changes to take effect.
On the sign in page there should now be a Google icon below the regular sign in form. Click the icon to begin the authentication process. Google will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in.
## Further Configuration
This further configuration is not required for Google authentication to function but it is strongly recommended. Taking these steps will increase usability for users by providing a little more recognition and branding.
At this point, when users first try to authenticate to your GitLab installation with Google they will see a generic application name on the prompt screen. The prompt informs the user that "Project Default Service Account" would like to access their account. "Project Default Service Account" isn't very recognizable and may confuse or cause users to be concerned. This is easily changeable.
1. Select 'Consent screen' in the left menu. (See steps 1, 4 and 5 above for instructions on how to get here if you closed your window).
2. Scroll down until you find "Product Name". Change the product name to something more descriptive.
3. Add any additional information as you wish - homepage, logo, privacy policy, etc. None of this is required, but it may help your users.
# OAuth
You can use other services to log into GitLab via oAuth.
For this you need:
* create app in selected services
* configure gitlab.yml
## Twitter:
Below are screenshots how to setup your app on Twitter for this:
![Application details](twitter_app_details.png)
![API Keys](twitter_app_api_keys.png)
## GitHub:
![GitHub app](github_app.png)
## Google:
![Google app](google_app.png)
## GitLab config file
Second step is to modify gitlab.yml with app credentials:
```
production:
...
omniauth:
enabled: true
providers:
- {
name: 'twitter',
app_id: 'XXXXXXXX',
app_secret: 'XXXXXXXXXXXXXXXXXXXXXXXX'
}
- {
name: 'google_oauth2',
app_id: 'XXXXXXXXXXX.apps.googleusercontent.com',
app_secret: 'XXXXXXXX'
}
- {
name: 'github',
app_id: 'XXXXXXXXXX',
app_secret: 'XXXXXXXXXXXXXXXXXXXXXXXX'
}
```
# OmniAuth
GitLab leverages OmniAuth to allow users to sign in using Twitter, GitHub, and other popular services. Configuring
OmniAuth does not prevent standard GitLab authentication or LDAP (if configured) from continuing to work. Users can
choose to sign in using any of the configured mechanisms.
+ [Initial OmniAuth Configuration](#initial-omniauth-configuration)
+ [Supported Providers](#supported-providers)
+ [Enable OmniAuth for an Existing User](#enable-omniauth-for-an-existing-user)
### Initial OmniAuth Configuration
Before configuring individual OmniAuth providers there are a few global settings that need to be verified.
1. Open the configuration file<br />
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
2. Find the section dealing with OmniAuth. The section will look similar to the following.<br />
```
## OmniAuth settings
omniauth:
# Allow login via Twitter, Google, etc. using OmniAuth providers
enabled: false
# CAUTION!
# This allows users to login without having a user account first (default: false).
# User accounts will be created automatically when authentication was successful.
allow_single_sign_on: false
# Locks down those users until they have been cleared by the admin (default: true).
block_auto_created_users: true
## Auth providers
# Uncomment the following lines and fill in the data of the auth provider you want to use
# If your favorite auth provider is not listed you can use others:
# see https://github.com/gitlabhq/gitlab-public-wiki/wiki/Custom-omniauth-provider-configurations
# The 'app_id' and 'app_secret' parameters are always passed as the first two
# arguments, followed by optional 'args' which can be either a hash or an array.
providers:
# - { name: 'google_oauth2', app_id: 'YOUR APP ID',
# app_secret: 'YOUR APP SECRET',
# args: { access_type: 'offline', approval_prompt: '' } }
# - { name: 'twitter', app_id: 'YOUR APP ID',
# app_secret: 'YOUR APP SECRET'}
# - { name: 'github', app_id: 'YOUR APP ID',
# app_secret: 'YOUR APP SECRET',
# args: { scope: 'user:email' } }
```
3. Change `enabled` to `true`.
4. Consider the next two configuration options: `allow_single_sign_on` and `block_auto_created_users`.
* `allow_single_sign_on` defaults to `false`. If `false` users must be created manually or they will not be able to
sign in via OmniAuth.
* `block_auto_created_users` defaults to `true`. If `true` auto created users will be blocked by default and will
have to be unblocked by an administrator before they are able to sign in.
* **Note:** If you set `allow_single_sign_on` to `true` and `block_auto_created_users` to `false` please be aware
that any user on the Internet will be able to successfully sign in to your GitLab without administrative approval.
5. Choose one or more of the Supported Providers below to continue configuration.
### Supported Providers
+ [GitHub](github.md)
+ [Google](google.md)
+ [Twitter](twitter.md)
### Enable OmniAuth for an Existing User
Existing users can enable OmniAuth for specific providers after the account is created. For example, if the user
originally signed in with LDAP an OmniAuth provider such as Twitter can be enabled. Follow the steps below to enable an
OmniAuth provider for an existing user.
1. Sign in normally - whether standard sign in, LDAP, or another OmniAuth provider.
2. Go to profile settings (the silhouette icon in the top right corner).
3. Select the "Account" tab.
4. Under "Social Accounts" select the desired OmniAuth provider, such as Twitter.
5. The user will be redirected to the provider. Once the user authorized GitLab they will be redirected back to GitLab.
The chosen OmniAuth provider is now active and can be used to sign in to GitLab from then on.
# Slack integration
### On Slack
To enable Slack integration you must create an Incoming WebHooks integration on Slack;
1. Sign in to [Slack](https://slack.com) (https://YOURSUBDOMAIN.slack.com/services)
2. Click on the Integrations menu at the top of the page.
3. Add a new Integration.
4. Pick Incoming WebHooks
5. Choose the channel name you want to send notifications to, in the Settings section
6. Add Integrations.
* Optional step; You can change bot's name and avatar by clicking "change the name of your bot", and "change the icon" after that you have to click "Save settings".
Now, Slack is ready to get external hooks. Before you leave this page don't forget to get the Token that you'll need on GitLab. You can find it by clicking Expand button, located in the "Instructions for creating Incoming WebHooks" section. It's a random alpha-numeric text 24 characters long.
### On GitLab
After Slack is ready we need to setup GitLab. Here are the steps to achieve this.
1. Sign in to GitLab
2. Pick the repository you want.
3. Navigate to Settings -> Services -> Slack
4. Fill in your Slack details
* Mark as active it
* Type your subdomain's prefix (If your subdomain is https://somedomain.slack.com you only have to type the somedomain)
* Type in the token you got from Slack
* Type in the channel name you want to use (eg. #announcements)
Have fun :)
_P.S. You can set "branch,pushed,Compare changes" as highlight words on your Slack profile settings, so that you can be aware of new commits when somebody pushes them._
# Twitter OAuth2 OmniAuth Provider
To enable the Twitter OmniAuth provider you must register your application with Twitter. Twitter will generate a client
ID and secret key for you to use.
1. Sign in to [Twitter Developers](https://dev.twitter.com/) area.
2. Hover over the avatar in the top right corner and select "My applications."
3. Select "Create new app"
4. Fill in the application details.
* Name: This can be anything. Consider something like "\<Organization\>'s GitLab" or "\<Your Name\>'s GitLab" or
something else descriptive.
* Description: Create a description.
* Website: The URL to your GitLab installation. 'https://gitlab.example.com'
* Callback URL: 'https://gitlab.example.com/users/auth/github/callback'
* Agree to the "Rules of the Road."
![Twitter App Details](twitter_app_details.png)
6. Select "Create your Twitter application."
7. Select the "Settings" tab.
8. Underneath the Callback URL check the box next to "Allow this application to be used to Sign in the Twitter."
9. Select "Update settings" at the bottom to save changes.
10. Select the "API Keys" tab.
11. You should now see an API key and API secret (see screenshot). Keep this page open as you continue configuration.
![Twitter app](twitter_app_api_keys.png)
12. On your GitLab server, open the configuration file.
```sh
cd /home/git/gitlab
sudo -u git -H editor config/gitlab.yml
```
13. Find the section dealing with OmniAuth. See [Initial OmniAuth Configuration](README.md#initial-omniauth-configuration)
for more details.
14. Under `providers:` uncomment (or add) lines that look like the following:
```
- { name: 'twitter', app_id: 'YOUR APP ID',
app_secret: 'YOUR APP SECRET' }
```
15. Change 'YOUR APP ID' to the API key from Twitter page in step 11.
16. Change 'YOUR APP SECRET' to the API secret from the Twitter page in step 11.
17. Save the configuration file.
18. Restart GitLab for the changes to take effect.
On the sign in page there should now be a Twitter icon below the regular sign in form. Click the icon to begin the
authentication process. Twitter will ask the user to sign in and authorize the GitLab application. If everything goes well the user will be returned to GitLab and will be signed in.
......@@ -17,6 +17,10 @@ NOTE: This is a guide for GitLab developers. If you are trying to install GitLab
#### 3. Do users need to update dependencies like `git`?
- Check the [GitLab Shell version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L782)
- Check the [Git version](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/tasks/gitlab/check.rake#L794)
#### 4. Get latest code
#### 5. Does GitLab shell need to be updated?
......@@ -72,3 +76,14 @@ After making the release branch new commits are cherry-picked from master. When
* Mention what GitLab is on the second line: GitLab is open source software to collaborate on code.
* Select and thank the the Most Valuable Person (MVP) of this release.
* Add a note if there are security fixes: This release fixes an important security issue and we advise everyone to upgrade as soon as possible.
# Tweet
Send out a tweet to share the good news with the world. For a major/minor release, list the features in short and link to the blog post.
For a RC, make sure to explain what a RC is.
A patch release tweet should specify the fixes it brings and link to the corresponding blog post.
# Things to do when doing a patch release
NOTE: This is a guide for GitLab developers. If you are trying to install GitLab see the latest stable [installation guide](install/installation.md) and if you are trying to upgrade, see the [upgrade guides](update).
## When to do a patch release
Do a patch release when there is a critical regression that needs to be adresses before the next monthly release.
Otherwise include it in the monthly release and note there was a regression fix in the release announcement.
## Release Procedure
1. Verify that the issue can be repoduced
1. Create an issue on private GitLab development server
1. Name the issue "Release X.X.X CE and X.X.X EE", this will make searching easier
1. Fix the issue on a feature branch, do this on the private GitLab development server
1. Consider creating and testing workarounds
1. After the branch is merged into master, cherry pick the commit(s) into the current stable branch
1. In a separate commit in the stable branch, update the VERSION and CHANGELOG
1. For EE, update the CHANGELOG-EE if it is EE specific fix. Otherwise, merge the stable CE branch and add to CHANGELOG-EE "Merge community edition changes for version X.X.X"
1. Create an annotated tag vX.X.X for CE and another patch release for EE
1. Make sure that the build has passed and no tests are failing
1. Push the code and the tags to all the CE and EE repositories
1. Apply the patch to GitLab Cloud and the private GitLab development server
1. Send tweets about the release from @gitlabhq, tweet should include the most important feature that the release is addressing as well as the link to the changelog
1. Build new packages with the latest version
......@@ -13,14 +13,8 @@ Please report suspected security vulnerabilities in private to support@gitlab.co
1. Verify that the issue can be repoduced
1. Acknowledge the issue to the researcher that disclosed it
1. Fix the issue on a feature branch, do this on the private GitLab development server and update the VERSION and CHANGELOG in this branch
1. Consider creating and testing workarounds
1. Do the steps from [patch release document](doc/release/patch.md), starting with "Create an issue on private GitLab development server"
1. Create feature branches for the blog post on GitLab.com and link them from the code branch
1. Merge the code feature branch into master
1. Cherry-pick the code into the latest stable branch
1. Create an annotated tag vX.X.X for CE and another patch release for EE
1. Push the code and the tags to all the CE and EE repositories
1. Apply the patch to GitLab Cloud and the private GitLab development server
1. Merge and publish the blog posts
1. Send tweets about the release from @gitlabhq
1. Send out an email to the subscribers mailing list on MailChimp
......
# From 6.7 to 6.8
### 0. Backup
```bash
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
```
### 1. Stop server
```bash
sudo service gitlab stop
```
### 2. Get latest code
```bash
cd /home/git/gitlab
sudo -u git -H git fetch --all
```
For Gitlab Community Edition:
```bash
sudo -u git -H git checkout 6-8-stable
```
OR
For GitLab Enterprise Edition:
```bash
sudo -u git -H git checkout 6-8-stable-ee
```
### 3. Update gitlab-shell (and its config)
```bash
cd /home/git/gitlab-shell
sudo -u git -H git fetch
sudo -u git -H git checkout v1.9.3
```
### 4. Install libs, migrations, etc.
```bash
cd /home/git/gitlab
# MySQL installations (note: the line below states '--without ... postgres')
sudo -u git -H bundle install --without development test postgres --deployment
# PostgreSQL installations (note: the line below states '--without ... mysql')
sudo -u git -H bundle install --without development test mysql --deployment
# Run database migrations
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
# Clean up assets and cache
sudo -u git -H bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production
# Update init.d script
sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab
# Update the logrotate configuration (keep logs for 90 days instead of 52 weeks)
sudo cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab
# Close access to gitlab-satellites for others
sudo chmod u+rwx,g+rx,o-rwx /home/git/gitlab-satellites
```
### 5. Update config files
#### New configuration options for gitlab.yml
There are new configuration options available for gitlab.yml. View them with the command below and apply them to your current gitlab.yml if desired.
```
git diff 6-7-stable:config/gitlab.yml.example 6-8-stable:config/gitlab.yml.example
```
#### MySQL? Remove reaping frequency
If you are using MySQL as a database, remove `reaping_frequency` from you database.yml to prevent crashes. [Relevant commit](https://gitlab.com/gitlab-org/gitlab-ce/commit/5163a8fcb9cfd63435560fda00173b76df2ccc93).
#### HTTPS? Disable gzip
If you are using HTTPS, disable gzip as in [this commit](https://gitlab.com/gitlab-org/gitlab-ce/commit/563fec734912d81cd7caea6fa8ec2b397fb72a9b) to prevent BREACH attacks.
#### Turn on asset compression
To improve performance, enable gzip asset compression as seen [in this commit](https://gitlab.com/gitlab-org/gitlab-ce/commit/8af94ed75505f0253823b9b2d44320fecea5b5fb).
### 6. Update Init script
```bash
sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab
sudo chmod +x /etc/init.d/gitlab
```
### 7. Start application
sudo service gitlab start
sudo service nginx restart
### 8. Check application status
Check if GitLab and its environment are configured correctly:
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production
To make sure you didn't miss anything run a more thorough check with:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production
If all items are green, then congratulations upgrade is complete!
## Things went south? Revert to previous version (6.7)
### 1. Revert the code to the previous version
Follow the [`upgrade guide from 6.6 to 6.7`](6.6-to-6.7.md), except for the database migration
(The backup is already migrated to the previous version)
### 2. Restore from the backup:
```bash
cd /home/git/gitlab
sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production
```
If you have more than one backup *.tar file(s) please add `BACKUP=timestamp_of_backup` to the command above.
+ [The indivual upgrade guides](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/update)
+ [Uprader](upgrader.md)
+ [The individual upgrade guides](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/update)
+ [Upgrader](upgrader.md)
+ [Ruby](ruby.md)
+ [Patch versions](patch_versions.md)
+ [MySQL to PostgreSQL](mysql_to_postgresql.md)
There are two main ways to have a merge request flow with GitLab: working with protected branches in a single repository, or working with forks of an authoritative project.
## Protected branch flow
With the protected branch flow everybody works within the same GitLab project.
The project maintainers get Master access and the regular developers get Developer access.
The maintainers mark the authoritative branches as 'Protected'.
The developers push feature branches to the project and create merge requests to have their feature branches reviewed and merged into one of the protected branches.
Only users with Master access can merge changes into a protected branch.
### Advantages
- fewer projects means less clutter
- developers need to consider only one remote repository
### Disadvantages
- manual setup of protected branch required for each new project
## Forking workflow
With the forking workflow the maintainers get Master access and the regular developers get Reporter access to the authoritative repository, which prohibits them from pushing any changes to it.
Developers create forks of the authoritative project and push their feature branches to their own forks.
To get their changes into master they need to create a merge request across forks.
### Advantages
- in an appropriately configured GitLab group, new projects automatically get the required access restrictions for regular developers: fewer manual steps to configure authorization for new projects
### Disadvantages
- the project need to keep their forks up to date, which requires more advanced Git skills (managing multiple remotes)
......@@ -83,7 +83,7 @@ class Spinach::Features::ProjectWiki < Spinach::FeatureSteps
Then 'I should see the existing page in the pages list' do
page.should have_content current_user.name
page.should have_content @page.title.titleize
page.should have_content @page.title
end
def wiki
......
......@@ -117,22 +117,22 @@ module API
class ProjectEntity < Grape::Entity
expose :id, :iid
expose (:project_id) { |entity| entity.project.id }
expose :title, :description
expose :state, :created_at, :updated_at
end
class Milestone < ProjectEntity
expose :title, :description, :due_date, :state, :updated_at, :created_at
expose :due_date
end
class Issue < ProjectEntity
expose :title, :description
expose :label_list, as: :labels
expose :milestone, using: Entities::Milestone
expose :assignee, :author, using: Entities::UserBasic
expose :state, :updated_at, :created_at
end
class MergeRequest < ProjectEntity
expose :target_branch, :source_branch, :title, :state, :upvotes, :downvotes, :description
expose :target_branch, :source_branch, :upvotes, :downvotes
expose :author, :assignee, using: Entities::UserBasic
expose :source_project_id, :target_project_id
end
......@@ -158,6 +158,7 @@ module API
expose :title, :project_id, :action_name
expose :target_id, :target_type, :author_id
expose :data, :target_title
expose :created_at
end
class LdapGroup < Grape::Entity
......
......@@ -19,14 +19,24 @@ module API
#
# Parameters:
# id (required) - The ID of a project
# state (optional) - Return requests "merged", "opened" or "closed"
#
# Example:
# GET /projects/:id/merge_requests
# GET /projects/:id/merge_requests?state=opened
# GET /projects/:id/merge_requests?state=closed
#
get ":id/merge_requests" do
authorize! :read_merge_request, user_project
present paginate(user_project.merge_requests), with: Entities::MergeRequest
mrs = case params["state"]
when "opened" then user_project.merge_requests.opened
when "closed" then user_project.merge_requests.closed
when "merged" then user_project.merge_requests.merged
else user_project.merge_requests
end
present paginate(mrs), with: Entities::MergeRequest
end
# Show MR
......
......@@ -118,7 +118,7 @@ module Gitlab
# merge the source branch into the satellite
# will raise CommandFailed when merge fails
repo.git.merge(default_options({no_ff: true}), "-m #{message}", "source/#{merge_request.source_branch}")
repo.git.merge(default_options({no_ff: true}), "-m#{message}", "source/#{merge_request.source_branch}")
rescue Grit::Git::CommandFailed => ex
handle_exception(ex)
end
......
module Gitlab
class SatelliteNotExistError < StandardError
def initialize(msg = "Satellite doesn't exist")
super
end
end
module Satellite
class Satellite
include Gitlab::Popen
......
Rake::Task["spec"].clear if Rake::Task.task_defined?('spec')
namespace :spec do
desc 'GITLAB | Run request specs'
task :api do
cmds = [
%W(rake gitlab:setup),
%W(rspec spec --tag @api)
]
run_commands(cmds)
end
desc 'GITLAB | Run feature specs'
task :feature do
cmds = [
%W(rake gitlab:setup),
%W(rspec spec --tag @feature)
]
run_commands(cmds)
end
desc 'GITLAB | Run other specs'
task :other do
cmds = [
%W(rake gitlab:setup),
%W(rspec spec --tag ~@api --tag ~@feature)
]
run_commands(cmds)
end
end
desc "GITLAB | Run specs"
task :spec do
cmds = [
%W(rake gitlab:setup),
%W(rspec spec),
]
run_commands(cmds)
end
def run_commands(cmds)
cmds.each do |cmd|
system({'RAILS_ENV' => 'test', 'force' => 'yes'}, *cmd)
raise "#{cmd} failed!" unless $?.exitstatus.zero?
......
require 'spec_helper'
describe "Admin::Hooks" do
describe "Admin::Hooks", feature: true do
before do
@project = create(:project)
login_as :admin
......
require 'spec_helper'
describe "Admin::Projects" do
describe "Admin::Projects", feature: true do
before do
@project = create(:project)
login_as :admin
......
require 'spec_helper'
describe "Admin::Users" do
describe "Admin::Users", feature: true do
before { login_as :admin }
describe "GET /admin/users" do
......
require 'spec_helper'
describe "Admin::Projects" do
describe "Admin::Projects", feature: true do
describe "GET /admin/projects" do
subject { admin_projects_path }
......
require 'spec_helper'
describe "Dashboard Issues Feed" do
describe "Dashboard Issues Feed", feature: true do
describe "GET /issues" do
let!(:user) { create(:user) }
let!(:project1) { create(:project) }
......
require 'spec_helper'
describe "Dashboard Feed" do
describe "Dashboard Feed", feature: true do
describe "GET /" do
let!(:user) { create(:user) }
......
require 'spec_helper'
describe "Issues Feed" do
describe "Issues Feed", feature: true do
describe "GET /issues" do
let!(:user) { create(:user) }
let!(:project) { create(:project) }
......
require 'spec_helper'
describe "GitLab Flavored Markdown" do
describe "GitLab Flavored Markdown", feature: true do
let(:project) { create(:project) }
let(:issue) { create(:issue, project: project) }
let(:merge_request) { create(:merge_request, source_project: project, target_project: project) }
......
require 'spec_helper'
describe "Issues" do
describe "Issues", feature: true do
let(:project) { create(:project) }
before do
......
require 'spec_helper'
describe "On a merge request", js: true do
describe "On a merge request", js: true, feature: true do
let!(:merge_request) { create(:merge_request, :simple) }
let!(:project) { merge_request.source_project }
let!(:note) { create(:note_on_merge_request, :with_attachment, project: project) }
......
require 'spec_helper'
describe "Profile account page" do
describe "Profile account page", feature: true do
before(:each) { enable_observers }
after(:each) {disable_observers}
let(:user) { create(:user) }
......
require 'spec_helper'
describe "Projects" do
describe "Projects", feature: true do
before(:each) { enable_observers }
after(:each) {disable_observers}
before { login_as :user }
......
require 'spec_helper'
describe "Search" do
describe "Search", feature: true do
before do
ActiveRecord::Base.observers.enable(:user_observer)
login_as :user
......
require 'spec_helper'
describe "Dashboard access" do
describe "Dashboard access", feature: true do
describe "GET /dashboard" do
subject { dashboard_path }
......
require 'spec_helper'
describe "Group access" do
describe "Group access", feature: true do
describe "GET /projects/new" do
it { new_group_path.should be_allowed_for :admin }
it { new_group_path.should be_allowed_for :user }
......
require 'spec_helper'
describe "Group with internal project access" do
describe "Group with internal project access", feature: true do
describe "Group" do
let(:group) { create(:group) }
......
require 'spec_helper'
describe "Group access" do
describe "Group access", feature: true do
describe "Group" do
let(:group) { create(:group) }
......
require 'spec_helper'
describe "Group with public project access" do
describe "Group with public project access", feature: true do
describe "Group" do
let(:group) { create(:group) }
......
require 'spec_helper'
describe "Users Security" do
describe "Users Security", feature: true do
describe "Project" do
before do
@u1 = create(:user)
......
require 'spec_helper'
describe "Internal Project Access" do
describe "Internal Project Access", feature: true do
let(:project) { create(:project, :internal) }
let(:master) { create(:user) }
......
require 'spec_helper'
describe "Private Project Access" do
describe "Private Project Access", feature: true do
let(:project) { create(:project) }
let(:master) { create(:user) }
......
require 'spec_helper'
describe "Public Project Access" do
describe "Public Project Access", feature: true do
let(:project) { create(:project) }
let(:master) { create(:user) }
......
require 'spec_helper'
describe 'Users' do
describe 'Users', feature: true do
describe "GET /users/sign_up" do
before do
Gitlab.config.gitlab.stub(:signup_enabled).and_return(true)
......
require 'spec_helper'
describe LabelsHelper do
describe '#label_css_class' do
it 'returns label-danger when given Bug as param' do
expect(label_css_class('bug')).to eq('label-danger')
end
it 'returns label-danger when given Bug as param' do
expect(label_css_class('Bug')).to eq('label-danger')
end
end
end
......@@ -502,7 +502,7 @@ describe Notify do
end
end
describe 'email on push' do
describe 'email on push with multiple commits' do
let(:example_site_path) { root_path }
let(:user) { create(:user) }
let(:compare) { Gitlab::Git::Compare.new(project.repository.raw_repository, 'cd5c4bac', 'b1e6a9db') }
......@@ -537,4 +537,40 @@ describe Notify do
should have_body_text /#{diff_path}/
end
end
describe 'email on push with a single commit' do
let(:example_site_path) { root_path }
let(:user) { create(:user) }
let(:compare) { Gitlab::Git::Compare.new(project.repository.raw_repository, '8716fc78', 'b1e6a9db') }
let(:commits) { Commit.decorate(compare.commits) }
let(:diff_path) { project_commit_path(project, commits.first) }
subject { Notify.repository_push_email(project.id, 'devs@company.name', user.id, 'master', compare) }
it 'is sent as the author' do
sender = subject.header[:from].addrs[0]
sender.display_name.should eq(user.name)
sender.address.should eq(gitlab_sender)
end
it 'is sent to recipient' do
should deliver_to 'devs@company.name'
end
it 'has the correct subject' do
should have_subject /New push to repository/
end
it 'includes commits list' do
should have_body_text /tree css fixes/
end
it 'includes diffs' do
should have_body_text /Checkout wiki pages for installation information/
end
it 'contains a link to the diff' do
should have_body_text /#{diff_path}/
end
end
end
......@@ -19,7 +19,7 @@
require 'spec_helper'
describe AssemblaService do
describe AssemblaService, models: true do
describe "Associations" do
it { should belong_to :project }
it { should have_one :service_hook }
......
......@@ -155,4 +155,20 @@ describe WikiPage do
end
end
describe "#title" do
before do
create_page("Title", "content")
@page = wiki.find_page("Title")
end
after do
destroy_page("Title")
end
it "should be replace a hyphen to a space" do
@page.title = "Import-existing-repositories-into-GitLab"
@page.title.should == "Import existing repositories into GitLab"
end
end
end
require 'spec_helper'
describe API do
describe API, api: true do
include API::APIHelpers
include ApiHelpers
let(:user) { create(:user) }
......@@ -158,4 +158,4 @@ describe API do
sudo_identifier.should == ' 123'
end
end
end
\ No newline at end of file
end
require 'spec_helper'
require 'mime/types'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { enable_observers }
after(:each) {disable_observers}
......
require 'spec_helper'
require 'mime/types'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { enable_observers }
after(:each) {disable_observers}
......
require 'spec_helper'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { ActiveRecord::Base.observers.enable(:user_observer) }
after(:each) { ActiveRecord::Base.observers.disable(:user_observer) }
......
require 'spec_helper'
describe API::API do
describe API::API, api: true do
include ApiHelpers
let(:user1) { create(:user) }
......
require 'spec_helper'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { ActiveRecord::Base.observers.enable(:user_observer) }
after(:each) { ActiveRecord::Base.observers.disable(:user_observer) }
......
require 'spec_helper'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { ActiveRecord::Base.observers.enable(:user_observer) }
after(:each) { ActiveRecord::Base.observers.disable(:user_observer) }
......
require "spec_helper"
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { ActiveRecord::Base.observers.enable(:user_observer) }
after(:each) { ActiveRecord::Base.observers.disable(:user_observer) }
let(:user) { create(:user) }
let!(:project) {create(:project, creator_id: user.id, namespace: user.namespace) }
let!(:merge_request) { create(:merge_request, :simple, author: user, assignee: user, source_project: project, target_project: project, title: "Test") }
let!(:merge_request_closed) { create(:merge_request, state: "closed", author: user, assignee: user, source_project: project, target_project: project, title: "Closed test") }
let!(:merge_request_merged) { create(:merge_request, state: "merged", author: user, assignee: user, source_project: project, target_project: project, title: "Merged test") }
let!(:note) { create(:note_on_merge_request, author: user, project: project, noteable: merge_request, note: "a comment on a MR") }
before {
project.team << [user, :reporters]
......@@ -21,12 +23,42 @@ describe API::API do
end
context "when authenticated" do
it "should return an array of merge_requests" do
it "should return an array of all merge_requests" do
get api("/projects/#{project.id}/merge_requests", user)
response.status.should == 200
json_response.should be_an Array
json_response.length.should == 3
json_response.first['title'].should == merge_request.title
end
it "should return an array of all merge_requests" do
get api("/projects/#{project.id}/merge_requests?state", user)
response.status.should == 200
json_response.should be_an Array
json_response.length.should == 3
json_response.first['title'].should == merge_request.title
end
it "should return an array of open merge_requests" do
get api("/projects/#{project.id}/merge_requests?state=opened", user)
response.status.should == 200
json_response.should be_an Array
json_response.length.should == 1
json_response.first['title'].should == merge_request.title
end
it "should return an array of closed merge_requests" do
get api("/projects/#{project.id}/merge_requests?state=closed", user)
response.status.should == 200
json_response.should be_an Array
json_response.length.should == 2
json_response.first['title'].should == merge_request_closed.title
json_response.second['title'].should == merge_request_merged.title
end
it "should return an array of merged merge_requests" do
get api("/projects/#{project.id}/merge_requests?state=merged", user)
response.status.should == 200
json_response.should be_an Array
json_response.length.should == 1
json_response.first['title'].should == merge_request_merged.title
end
end
end
......
require 'spec_helper'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { enable_observers }
after(:each) {disable_observers}
......
require 'spec_helper'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { ActiveRecord::Base.observers.enable(:user_observer) }
after(:each) { ActiveRecord::Base.observers.disable(:user_observer) }
......
require 'spec_helper'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { ActiveRecord::Base.observers.enable(:user_observer) }
after(:each) { ActiveRecord::Base.observers.disable(:user_observer) }
......
require 'spec_helper'
describe API::API, 'ProjectHooks' do
describe API::API, 'ProjectHooks', api: true do
include ApiHelpers
before(:each) { enable_observers }
after(:each) { disable_observers }
......
require 'spec_helper'
describe API::API do
describe API::API, api: true do
include ApiHelpers
before(:each) { enable_observers }
after(:each) { disable_observers }
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
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