Merge branch 'master' of gitlab.com:gitlab-org/gitlab-ce into ce_upstream

app/models/issue.rb

@@ -112,7 +112,7 @@ class Issue < ActiveRecord::Base
 
   def related_branches
     project.repository.branch_names.select do |branch|
-      branch.end_with?("-#{iid}")
+      branch =~ /\A#{iid}-(?!\d+-stable)/i
     end
   end
 
@@ -161,7 +161,7 @@ class Issue < ActiveRecord::Base
   end
 
   def to_branch_name
-    "#{title.parameterize}-#{iid}"
+    "#{iid}-#{title.parameterize}"
   end
 
   def can_be_worked_on?(current_user)

app/services/merge_requests/build_service.rb

@@ -56,7 +56,7 @@ module MergeRequests
       # be interpreted as the use wants to close that issue on this project
       # Pattern example: 112-fix-mep-mep
       # Will lead to appending `Closes #112` to the description
-      if match = merge_request.source_branch.match(/-(\d+)\z/)
+      if match = merge_request.source_branch.match(/\A(\d+)-/)
         iid = match[1]
         closes_issue = "Closes ##{iid}"
 

app/services/system_note_service.rb

@@ -222,7 +222,7 @@ class SystemNoteService
   # Called when a branch is created from the 'new branch' button on a issue
   # Example note text:
   #
-  #   "Started branch `issue-branch-button-201`"
+  #   "Started branch `201-issue-branch-button`"
   def self.new_issue_branch(issue, project, author, branch)
     h = Gitlab::Routing.url_helpers
     link = h.namespace_project_compare_url(project.namespace, project, from: project.default_branch, to: branch)

bin/setup

@@ -18,7 +18,7 @@ Dir.chdir APP_ROOT do
   # end
 
   puts "\n== Preparing database =="
-  system "bin/rake db:setup"
+  system "bin/rake db:reset"
 
   puts "\n== Removing old logs and tempfiles =="
   system "rm -f log/*"

doc/ci/yaml/README.md

 # Configuration of your builds with .gitlab-ci.yml
 
+This document describes the usage of `.gitlab-ci.yml`, the file that is used by
+GitLab Runner to manage your project's builds.
+
+If you want a quick introduction to GitLab CI, follow our
+[quick start guide](../quick_start/README.md).
+
+---
+
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+**Table of Contents**  *generated with [DocToc](https://github.com/thlorenz/doctoc)*
+
+- [.gitlab-ci.yml](#gitlab-ci-yml)
+    - [image and services](#image-and-services)
+    - [before_script](#before_script)
+    - [stages](#stages)
+    - [types](#types)
+    - [variables](#variables)
+    - [cache](#cache)
+        - [cache:key](#cache-key)
+- [Jobs](#jobs)
+    - [script](#script)
+    - [stage](#stage)
+    - [only and except](#only-and-except)
+    - [tags](#tags)
+    - [when](#when)
+    - [artifacts](#artifacts)
+        - [artifacts:name](#artifacts-name)
+    - [dependencies](#dependencies)
+- [Hidden jobs](#hidden-jobs)
+- [Special YAML features](#special-yaml-features)
+    - [Anchors](#anchors)
+- [Validate the .gitlab-ci.yml](#validate-the-gitlab-ci-yml)
+- [Skipping builds](#skipping-builds)
+- [Examples](#examples)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+---
+
+## .gitlab-ci.yml
+
 From version 7.12, GitLab CI uses a [YAML](https://en.wikipedia.org/wiki/YAML)
 file (`.gitlab-ci.yml`) for the project configuration. It is placed in the root
 of your repository and contains definitions of how your project should be built.
@@ -23,12 +65,10 @@ Of course a command can execute code directly (`./configure;make;make install`)
 or run a script (`test.sh`) in the repository.
 
 Jobs are used to create builds, which are then picked up by
-[runners](../runners/README.md) and executed within the environment of the
-runner. What is important, is that each job is run independently from each
+[Runners](../runners/README.md) and executed within the environment of the
+Runner. What is important, is that each job is run independently from each
 other.
 
-## .gitlab-ci.yml
-
 The YAML syntax allows for using more complex job specifications than in the
 above example:
 
@@ -71,7 +111,7 @@ There are a few reserved `keywords` that **cannot** be used as job names:
 
 This allows to specify a custom Docker image and a list of services that can be
 used for time of the build. The configuration of this feature is covered in
-separate document: [Use Docker](../docker/README.md).
+[a separate document](../docker/README.md).
 
 ### before_script
 
@@ -86,7 +126,8 @@ The specification of `stages` allows for having flexible multi stage pipelines.
 The ordering of elements in `stages` defines the ordering of builds' execution:
 
 1. Builds of the same stage are run in parallel.
-1. Builds of next stage are run after success.
+1. Builds of the next stage are run after the jobs from the previous stage
+   complete successfully.
 
 Let's consider the following example, which defines 3 stages:
 
@@ -98,9 +139,9 @@ stages:
 ```
 
 1. First all jobs of `build` are executed in parallel.
-1. If all jobs of `build` succeeds, the `test` jobs are executed in parallel.
-1. If all jobs of `test` succeeds, the `deploy` jobs are executed in parallel.
-1. If all jobs of `deploy` succeeds, the commit is marked as `success`.
+1. If all jobs of `build` succeed, the `test` jobs are executed in parallel.
+1. If all jobs of `test` succeed, the `deploy` jobs are executed in parallel.
+1. If all jobs of `deploy` succeed, the commit is marked as `success`.
 1. If any of the previous jobs fails, the commit is marked as `failed` and no
    jobs of further stage are executed.
 
@@ -278,14 +319,14 @@ job_name:
 
 | Keyword       | Required | Description |
 |---------------|----------|-------------|
-| script        | yes | Defines a shell script which is executed by runner |
+| script        | yes | Defines a shell script which is executed by Runner |
 | image         | no | Use docker image, covered in [Using Docker Images](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml) |
 | services      | no | Use docker services, covered in [Using Docker Images](../docker/using_docker_images.md#define-image-and-services-from-gitlab-ciyml) |
 | stage         | no | Defines a build stage (default: `test`) |
 | type          | no | Alias for `stage` |
 | only          | no | Defines a list of git refs for which build is created |
 | except        | no | Defines a list of git refs for which build is not created |
-| tags          | no | Defines a list of tags which are used to select runner |
+| tags          | no | Defines a list of tags which are used to select Runner |
 | allow_failure | no | Allow build to fail. Failed build doesn't contribute to commit status |
 | when          | no | Define when to run build. Can be `on_success`, `on_failure` or `always` |
 | dependencies  | no | Define other builds that a build depends on so that you can pass artifacts between them|
@@ -294,7 +335,7 @@ job_name:
 
 ### script
 
-`script` is a shell script which is executed by the runner. For example:
+`script` is a shell script which is executed by the Runner. For example:
 
 ```yaml
 job:
@@ -375,13 +416,13 @@ except master.
 
 ### tags
 
-`tags` is used to select specific runners from the list of all runners that are
+`tags` is used to select specific Runners from the list of all Runners that are
 allowed to run this project.
 
-During the registration of a runner, you can specify the runner's tags, for
+During the registration of a Runner, you can specify the Runner's tags, for
 example `ruby`, `postgres`, `development`.
 
-`tags` allow you to run builds with runners that have the specified tags
+`tags` allow you to run builds with Runners that have the specified tags
 assigned to them:
 
 ```yaml
@@ -391,7 +432,7 @@ job:
     - postgres
 ```
 
-The specification above, will make sure that `job` is built by a runner that
+The specification above, will make sure that `job` is built by a Runner that
 has both `ruby` AND `postgres` tags defined.
 
 ### when

doc/development/rake_tasks.md

@@ -9,7 +9,7 @@ bundle exec rake setup
 ```
 
 The `setup` task is a alias for `gitlab:setup`.
-This tasks calls `db:setup` to create the database, calls `add_limits_mysql` that adds limits to the database schema in case of a MySQL database and finally it calls `db:seed_fu` to seed the database.
+This tasks calls `db:reset` to create the database, calls `add_limits_mysql` that adds limits to the database schema in case of a MySQL database and finally it calls `db:seed_fu` to seed the database.
 Note: `db:setup` calls `db:seed` but this does nothing.
 
 ## Run tests

doc/integration/shibboleth.md

@@ -76,3 +76,50 @@ sudo gitlab-ctl reconfigure
 ```
 
 On the sign in page there should now be a "Sign in with: Shibboleth" icon below the regular sign in form. Click the icon to begin the authentication process. You will be redirected to IdP server (Depends on your Shibboleth module configuration). If everything goes well the user will be returned to GitLab and will be signed in.
+
+## Apache 2.4 / GitLab 8.6 update
+The order of the first 2 Location directives is important. If they are reversed,
+you will not get a shibboleth session!
+
+```
+  <Location />
+    Require all granted
+    ProxyPassReverse http://127.0.0.1:8181
+    ProxyPassReverse http://YOUR_SERVER_FQDN/
+  </Location>
+
+  <Location /users/auth/shibboleth/callback>
+    AuthType shibboleth
+    ShibRequestSetting requireSession 1
+    ShibUseHeaders On
+    Require shib-session
+  </Location>
+
+  Alias /shibboleth-sp /usr/share/shibboleth
+
+  <Location /shibboleth-sp>
+    Require all granted
+  </Location>
+
+  <Location /Shibboleth.sso>
+    SetHandler shib
+  </Location>
+
+  RewriteEngine on
+
+  #Don't escape encoded characters in api requests
+  RewriteCond %{REQUEST_URI} ^/api/v3/.*
+  RewriteCond %{REQUEST_URI} !/Shibboleth.sso
+  RewriteCond %{REQUEST_URI} !/shibboleth-sp
+  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA,NE]
+
+  #Forward all requests to gitlab-workhorse except existing files
+  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR]
+  RewriteCond %{REQUEST_URI} ^/uploads/.*
+  RewriteCond %{REQUEST_URI} !/Shibboleth.sso
+  RewriteCond %{REQUEST_URI} !/shibboleth-sp
+  RewriteRule .* http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]
+
+  RequestHeader set X_FORWARDED_PROTO 'https'
+  RequestHeader set X-Forwarded-Ssl on
+```
\ No newline at end of file

doc/workflow/web_editor.md

@@ -85,7 +85,7 @@ Once you click it, a new branch will be created that diverges from the default
 branch of your project, by default `master`. The branch name will be based on
 the title of the issue and as suffix it will have its ID. Thus, the example
 screenshot above will yield a branch named
-`et-cum-et-sed-expedita-repellat-consequatur-ut-assumenda-numquam-rerum-2`.
+`2-et-cum-et-sed-expedita-repellat-consequatur-ut-assumenda-numquam-rerum`.
 
 After the branch is created, you can edit files in the repository to fix
 the issue. When a merge request is created based on the newly created branch,

lib/tasks/gitlab/setup.rake

@@ -14,7 +14,7 @@ namespace :gitlab do
       puts ""
     end
 
-    Rake::Task["db:setup"].invoke
+    Rake::Task["db:reset"].invoke
     Rake::Task["add_limits_mysql"].invoke
     Rake::Task["setup_postgresql"].invoke
     Rake::Task["db:seed_fu"].invoke

spec/models/issue_spec.rb

@@ -191,12 +191,19 @@ describe Issue, models: true do
   end
 
   describe '#related_branches' do
-    it "selects the right branches" do
+    it 'selects the right branches' do
       allow(subject.project.repository).to receive(:branch_names).
-        and_return(["mpempe", "#{subject.iid}mepmep", subject.to_branch_name])
+        and_return(['mpempe', "#{subject.iid}mepmep", subject.to_branch_name])
 
       expect(subject.related_branches).to eq([subject.to_branch_name])
     end
+
+    it 'excludes stable branches from the related branches' do
+      allow(subject.project.repository).to receive(:branch_names).
+        and_return(["#{subject.iid}-0-stable"])
+
+      expect(subject.related_branches).to eq []
+    end
   end
 
   it_behaves_like 'an editable mentionable' do
@@ -210,11 +217,11 @@ describe Issue, models: true do
     let(:subject) { create :issue }
   end
 
-  describe "#to_branch_name" do
+  describe '#to_branch_name' do
     let(:issue) { create(:issue, title: 'a' * 30) }
 
-    it "starts with the issue iid" do
-      expect(issue.to_branch_name).to match /-#{issue.iid}\z/
+    it 'starts with the issue iid' do
+      expect(issue.to_branch_name).to match /\A#{issue.iid}-a+\z/
     end
   end
 end