Merge branch 'master' into branch-invalid-name

CHANGELOG

 Please view this file on the master branch, on stable branches it's out of date.
 
 v 8.3.0 (unreleased)
+  - API support for starred projects for authorized user (Zeger-Jan van de Weg)
   - Add open_issues_count to project API (Stan Hu)
   - Expand character set of usernames created by Omniauth (Corey Hinshaw)
   - Add button to automatically merge a merge request when the build succeeds (Zeger-Jan van de Weg)
-  - Merge when build succeeds (Zeger-Jan van de Weg)
   - Provide better diagnostic message upon project creation errors (Stan Hu)
   - Bump devise to 3.5.3 to fix reset token expiring after account creation (Stan Hu)
   - Bump gollum-lib to 4.1.0 (Stan Hu)

GITLAB_SHELL_VERSION

-2.6.8
+2.6.9

GITLAB_WORKHORSE_VERSION

-0.5.0
+0.5.1

Gemfile

@@ -251,7 +251,7 @@ group :development, :test do
 
   gem 'capybara',            '~> 2.4.0'
   gem 'capybara-screenshot', '~> 1.0.0'
-  gem 'poltergeist',         '~> 1.6.0'
+  gem 'poltergeist',         '~> 1.8.1'
 
   gem 'teaspoon', '~> 1.0.0'
   gem 'teaspoon-jasmine', '~> 2.2.0'

Gemfile.lock

@@ -405,7 +405,7 @@ GEM
     method_source (0.8.2)
     mime-types (1.25.1)
     mimemagic (0.3.0)
-    mini_portile (0.6.2)
+    mini_portile2 (2.0.0)
     minitest (5.7.0)
     mousetrap-rails (1.4.6)
     multi_json (1.11.2)
@@ -420,8 +420,8 @@ GEM
       grape
       newrelic_rpm
     newrelic_rpm (3.9.4.245)
-    nokogiri (1.6.6.4)
-      mini_portile (~> 0.6.0)
+    nokogiri (1.6.7)
+      mini_portile2 (~> 2.0.0.rc2)
     nprogress-rails (0.1.6.7)
     oauth (0.4.7)
     oauth2 (1.0.0)
@@ -488,7 +488,7 @@ GEM
     parser (2.2.3.0)
       ast (>= 1.1, < 3.0)
     pg (0.18.4)
-    poltergeist (1.6.0)
+    poltergeist (1.8.1)
       capybara (~> 2.1)
       cliver (~> 0.3.1)
       multi_json (~> 1.0)
@@ -905,7 +905,7 @@ DEPENDENCIES
   org-ruby (~> 0.9.12)
   paranoia (~> 2.0)
   pg (~> 0.18.2)
-  poltergeist (~> 1.6.0)
+  poltergeist (~> 1.8.1)
   pry-rails
   quiet_assets (~> 1.0.2)
   rack-attack (~> 4.3.0)

app/assets/javascripts/issuable_context.js.coffee

@@ -18,7 +18,7 @@ class @IssuableContext
 
       $('.issuable-affix').affix offset:
         top: ->
-          @top = ($('.issuable-affix').offset().top - 60)
+          @top = ($('.issuable-affix').offset().top - 70)
         bottom: ->
           @bottom = $('.footer').outerHeight(true)
 

app/assets/stylesheets/pages/issuable.scss

@@ -18,7 +18,7 @@
 
     &.affix {
       position: fixed;
-      top: 60px;
+      top: 70px;
       margin-right: 35px;
     }
   }
@@ -39,16 +39,9 @@
   section {
     border-right: 1px solid $border-white-light;
 
-    > .tab-content {
+    .issuable-discussion {
       margin-right: 1px;
     }
-
-    .issue-discussion > .gray-content-block,
-    > .gray-content-block {
-      margin-top: 0;
-      border-top: none;
-      margin-right: -15px;
-    }
   }
 }
 

app/assets/stylesheets/pages/issues.scss

@@ -141,18 +141,6 @@ form.edit-issue {
   }
 }
 
-.issue-closed-by-widget {
-  padding: 16px 0;
-  margin: 0px;
-}
-
 .issue-form .select2-container {
   width: 250px !important;
 }
-
-
-.issue-discussion {
-  .common-note-form {
-    border-right: 1px solid $border-white-light;
-  }
-}

app/views/projects/issues/_closed_by_box.html.haml

-.issue-closed-by-widget
-  = icon('check')
+.issue-closed-by-widget.gray-content-block.second-block.white
   This issue will be closed automatically when merge request #{markdown(merge_requests_sentence(@closed_by_merge_requests), pipeline: :gfm)} is accepted.

app/views/projects/issues/_discussion.html.haml

@@ -5,8 +5,5 @@
     - else
       = link_to 'Close Issue', issue_path(@issue, issue: {state_event: :close}, status_only: true), method: :put, class: 'btn btn-grouped btn-close js-note-target-close', title: 'Close Issue'
 
-.gray-content-block.second-block.oneline-block
-  = render 'votes/votes_block', votable: @issue
-
 #notes
   = render 'projects/notes/notes_with_form'

app/views/projects/issues/show.html.haml

@@ -37,9 +37,7 @@
           Edit
 
   .issue-details.issuable-details
-    .row
-      %section.col-md-9
-        .detail-page-description.gray-content-block
+    .detail-page-description.gray-content-block.second-block
       %h2.title
         = markdown escape_once(@issue.title), pipeline: :single_line
       %div
@@ -54,9 +52,15 @@
         .merge-requests
           = render 'merge_requests'
 
+    .gray-content-block.second-block.oneline-block
+      = render 'votes/votes_block', votable: @issue
+
     - if @closed_by_merge_requests.present?
       = render 'projects/issues/closed_by_box'
-        .issue-discussion
+
+    .row
+      %section.col-md-9
+        .issuable-discussion
           = render 'projects/issues/discussion'
 
       %aside.col-md-3

app/views/projects/merge_requests/_discussion.html.haml

@@ -5,7 +5,4 @@
     - if @merge_request.closed?
       = link_to 'Reopen', merge_request_path(@merge_request, merge_request: {state_event: :reopen }), method: :put, class: "btn btn-grouped btn-reopen reopen-mr-link js-note-target-reopen", title: "Reopen merge request"
 
-.gray-content-block.second-block.oneline-block
-  = render 'votes/votes_block', votable: @merge_request
-
 #notes= render "projects/notes/notes_with_form"

app/views/projects/merge_requests/_new_submit.html.haml

@@ -23,15 +23,15 @@
       = link_to url_for(params), data: {target: 'div#commits', action: 'commits', toggle: 'tab'} do
         Commits
         %span.badge= @commits.size
-    %li.diffs-tab.active
-      = link_to url_for(params), data: {target: 'div#diffs', action: 'diffs', toggle: 'tab'} do
-        Changes
-        %span.badge= @diffs.size
     - if @ci_commit
       %li.builds-tab.active
         = link_to url_for(params), data: {target: 'div#builds', action: 'builds', toggle: 'tab'} do
           Builds
           %span.badge= @statuses.size
+    %li.diffs-tab.active
+      = link_to url_for(params), data: {target: 'div#diffs', action: 'diffs', toggle: 'tab'} do
+        Changes
+        %span.badge= @diffs.size
 
   .tab-content
     #commits.commits.tab-pane

app/views/projects/merge_requests/_show.html.haml

@@ -8,8 +8,6 @@
   = render "projects/merge_requests/show/mr_title"
 
   .merge-request-details.issuable-details
-    .row
-      %section.col-md-9
     = render "projects/merge_requests/show/mr_box"
     .append-bottom-default.mr-source-target.prepend-top-default
       - if @merge_request.open?
@@ -53,35 +51,39 @@
           = link_to commits_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#commits', action: 'commits', toggle: 'tab'} do
             Commits
             %span.badge= @commits.size
-            %li.diffs-tab
-              = link_to diffs_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#diffs', action: 'diffs', toggle: 'tab'} do
-                Changes
-                %span.badge= @merge_request.diffs.size
         - if @ci_commit
           %li.builds-tab
             = link_to builds_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: '#builds', action: 'builds', toggle: 'tab'} do
               Builds
               %span.badge= @statuses.size
+        %li.diffs-tab
+          = link_to diffs_namespace_project_merge_request_path(@project.namespace, @project, @merge_request), data: {target: 'div#diffs', action: 'diffs', toggle: 'tab'} do
+            Changes
+            %span.badge= @merge_request.diffs.size
 
       .tab-content
         #notes.notes.tab-pane.voting_notes
+          .gray-content-block.second-block.oneline-block
+            = render 'votes/votes_block', votable: @merge_request
+
+          .row
+            %section.col-md-9
+              .issuable-discussion
                 = render "projects/merge_requests/discussion"
+            %aside.col-md-3
+              = render 'shared/issuable/sidebar', issuable: @merge_request
+            = render 'shared/show_aside'
+
         #commits.commits.tab-pane
           - # This tab is always loaded via AJAX
-          #diffs.diffs.tab-pane
-            - # This tab is always loaded via AJAX
         #builds.builds.tab-pane
           - # This tab is always loaded via AJAX
+        #diffs.diffs.tab-pane
+          - # This tab is always loaded via AJAX
 
       .mr-loading-status
         = spinner
 
-      %aside.col-md-3
-        = render 'shared/issuable/sidebar', issuable: @merge_request
-
-      = render 'shared/show_aside'
-
-
 :javascript
   var merge_request;
 

app/views/projects/merge_requests/show/_mr_box.html.haml

-.detail-page-description.gray-content-block.middle-block
+.detail-page-description.gray-content-block.second-block
   %h2.title
     = markdown escape_once(@merge_request.title), pipeline: :single_line
 

app/views/projects/merge_requests/widget/open/_accept.html.haml

@@ -7,13 +7,13 @@
       .accept-action
         - if @ci_commit && @ci_commit.active?
           %span.btn-group
-            = link_to "#", class: "btn btn-create merge_when_build_succeeds" do
+            = button_tag class: "btn btn-create js-merge-button merge_when_build_succeeds" do
               Merge When Build Succeeds
-            %a.btn.btn-success.dropdown-toggle{ 'data-toggle' => 'dropdown' }
+            = button_tag class: "btn btn-success dropdown-toggle", 'data-toggle' => 'dropdown' do
               %span.caret
               %span.sr-only
                 Select Merge Moment
-            %ul.dropdown-menu.dropdown-menu-right{ role: 'menu' }
+            %ul.js-merge-dropdown.dropdown-menu.dropdown-menu-right{ role: 'menu' }
               %li
                 = link_to "#", class: "merge_when_build_succeeds" do
                   = icon('check fw')
@@ -23,7 +23,7 @@
                   = icon('warning fw')
                   Merge Immediately
         - else
-          = f.button class: "btn btn-create btn-grouped accept_merge_request #{status_class}" do
+          = f.button class: "btn btn-create btn-grouped js-merge-button accept_merge_request #{status_class}" do
             Accept Merge Request
       - if @merge_request.can_remove_source_branch?(current_user)
         .accept-control.checkbox
@@ -42,21 +42,19 @@
     = hidden_field_tag :merge_when_build_succeeds, "", autocomplete: "off"
 
   :javascript
-    $('.accept_merge_request').on('click', function() {
-      $(this).html("<i class='fa fa-spinner fa-spin'></i> Merge in progress");
-    });
-
     $('.accept-mr-form').on('ajax:send', function() {
       $(".accept-mr-form :input").disable();
     });
 
-    $('a.accept_merge_request').on('click', function(e) {
-      e.preventDefault();
-      $(this).closest("form").submit();
+    $('.accept_merge_request').on('click', function() {
+      $('.js-merge-button').html("<i class='fa fa-spinner fa-spin'></i> Merge in progress");
     });
 
-    $('a.merge_when_build_succeeds').on('click', function(e) {
-      e.preventDefault();
+    $('.merge_when_build_succeeds').on('click', function() {
       $("#merge_when_build_succeeds").val("1");
+    });
+
+    $('.js-merge-dropdown a').on('click', function(e) {
+      e.preventDefault();
       $(this).closest("form").submit();
     });

app/views/projects/tree/_tree_header.html.haml

@@ -20,16 +20,24 @@
           %li
             = link_to namespace_project_new_blob_path(@project.namespace, @project, @id), title: 'Create file', id: 'new-file-link' do
               = icon('pencil fw')
-              Create file
+              New file
           %li
             = link_to '#modal-upload-blob', { 'data-target' => '#modal-upload-blob', 'data-toggle' => 'modal'} do
               = icon('file fw')
               Upload file
-          %li.divider
           %li
             = link_to '#modal-create-new-dir', { 'data-target' => '#modal-create-new-dir', 'data-toggle' => 'modal'} do
               = icon('folder fw')
               New directory
+          %li.divider
+          %li
+            = link_to new_namespace_project_branch_path(@project.namespace, @project) do
+              = icon('code-fork fw')
+              New branch
+          %li
+            = link_to new_namespace_project_tag_path(@project.namespace, @project) do
+              = icon('tags fw')
+              New tag
   - elsif !on_top_of_branch?
     %li
       %span.btn.btn-sm.add-to-tree.disabled.has_tooltip{title: "You can only add files when you are on a branch.", data: {container: 'body'}}

db/migrate/20151210125930_migrate_ci_to_project.rb

@@ -26,7 +26,8 @@ class MigrateCiToProject < ActiveRecord::Migration
 
   def migrate_project_column(column, new_column = nil)
     new_column ||= column
-    subquery = "SELECT ci_projects.#{column} FROM ci_projects WHERE projects.id = ci_projects.gitlab_id"
+    subquery = "SELECT ci_projects.#{column} FROM ci_projects WHERE projects.id = ci_projects.gitlab_id " \
+      'ORDER BY ci_projects.updated_at DESC LIMIT 1'
     execute("UPDATE projects SET #{new_column}=(#{subquery}) WHERE (#{subquery}) IS NOT NULL")
   end
 

doc/api/projects.md

@@ -139,6 +139,21 @@ Parameters:
 - `sort` (optional) - Return requests sorted in `asc` or `desc` order. Default is `desc`
 - `search` (optional) - Return list of authorized projects according to a search criteria
 
+### List starred projects
+
+Get a list of projects which are starred by the authenticated user.
+
+```
+GET /projects/starred
+```
+
+Parameters:
+
+- `archived` (optional) - if passed, limit by archived status
+- `order_by` (optional) - Return requests ordered by `id`, `name`, `path`, `created_at`, `updated_at` or `last_activity_at` fields. Default is `created_at`
+- `sort` (optional) - Return requests sorted in `asc` or `desc` order. Default is `desc`
+- `search` (optional) - Return list of authorized projects according to a search criteria
+
 ### List ALL projects
 
 Get a list of all GitLab projects (admin only).

doc/ci/docker/using_docker_images.md

 # Using Docker Images
 
-GitLab CI in conjuction with [GitLab Runner](../runners/README.md) can use
+GitLab CI in conjunction with [GitLab Runner](../runners/README.md) can use
 [Docker Engine](https://www.docker.com/) to test and build any application.
 
 Docker is an open-source project that allows you to use predefined images to
 run applications in independent "containers" that are run within a single Linux
-instance. [Docker Hub][hub] has a rich database of prebuilt images that can be
+instance. [Docker Hub][hub] has a rich database of pre-built images that can be
 used to test and build your applications.
 
 Docker, when used with GitLab CI, runs each build in a separate and isolated
@@ -136,6 +136,24 @@ Look for the `[runners.docker]` section:
 The image and services defined this way will be added to all builds run by
 that runner.
 
+## Define an image from a private Docker registry
+
+Starting with GitLab Runner 0.6.0, you are able to define images located to
+private registries that could also require authentication.
+
+All you have to do is be explicit on the image definition in `.gitlab-ci.yml`.
+
+```yaml
+image: my.registry.tld:5000/namepace/image:tag
+```
+
+In the example above, GitLab Runner will look at `my.registry.tld:5000` for the
+image `namespace/image:tag`.
+
+If the repository is private you need to authenticate your GitLab Runner in the
+registry. Learn how to do that on
+[GitLab Runner's documentation][runner-priv-reg].
+
 ## Accessing the services
 
 Let's say that you need a Wordpress instance to test some API integration with
@@ -258,3 +276,4 @@ creation.
 [tutum/wordpress]: https://registry.hub.docker.com/u/tutum/wordpress/
 [postgres-hub]: https://registry.hub.docker.com/u/library/postgres/
 [mysql-hub]: https://registry.hub.docker.com/u/library/mysql/
+[runner-priv-reg]: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/configuration/advanced-configuration.md#using-a-private-docker-registry

doc/ci/yaml/README.md

 # Configuration of your builds with .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.
 
-The YAML file defines a set of jobs with constraints stating when they should be run.
-The jobs are defined as top-level elements with a name and always have to contain the `script` clause:
+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.
+
+The YAML file defines a set of jobs with constraints stating when they should
+be run. The jobs are defined as top-level elements with a name and always have
+to contain the `script` clause:
 
 ```yaml
 job1:
@@ -13,15 +16,21 @@ job2:
   script: "execute-script-for-job2"
 ```
 
-The above example is the simplest possible CI configuration with two separate jobs,
-where each of the jobs executes a different command.
-Of course a command can execute code directly (`./configure;make;make install`) or run a script (`test.sh`) in the repository.
+The above example is the simplest possible CI configuration with two separate
+jobs, where each of the jobs executes a different command.
+
+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 other.
+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
+other.
 
 ## .gitlab-ci.yml
-The YAML syntax allows for using more complex job specifications than in the above example:
+
+The YAML syntax allows for using more complex job specifications than in the
+above example:
 
 ```yaml
 image: ruby:2.1
@@ -46,26 +55,31 @@ job1:
     - docker
 ```
 
-There are a few `keywords` that can't be used as job names:
+There are a few reserved `keywords` that **cannot** be used as job names:
 
-| keyword       | required | description |
+| Keyword       | Required | Description |
 |---------------|----------|-------------|
-| image         | optional | Use docker image, covered in [Use Docker](../docker/README.md) |
-| services      | optional | Use docker services, covered in [Use Docker](../docker/README.md) |
-| stages        | optional | Define build stages |
-| types         | optional | Alias for `stages` |
-| before_script | optional | Define commands prepended for each job's script |
-| variables     | optional | Define build variables |
-| cache         | optional | Define list of files that should be cached between subsequent runs |
+| image         | no | Use docker image, covered in [Use Docker](../docker/README.md) |
+| services      | no | Use docker services, covered in [Use Docker](../docker/README.md) |
+| stages        | no | Define build stages |
+| types         | no | Alias for `stages` |
+| before_script | no | Define commands that run before each job's script |
+| variables     | no | Define build variables |
+| cache         | no | Define list of files that should be cached between subsequent runs |
 
 ### image and services
-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).
+
+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).
 
 ### before_script
-`before_script` is used to define the command that should be run before all builds, including deploy builds. This can be an array or a multiline string.
+
+`before_script` is used to define the command that should be run before all
+builds, including deploy builds. This can be an array or a multi-line string.
 
 ### stages
+
 `stages` is used to define build stages that can be used by jobs.
 The specification of `stages` allows for having flexible multi stage pipelines.
 
@@ -75,7 +89,8 @@ The ordering of elements in `stages` defines the ordering of builds' execution:
 1. Builds of next stage are run after success.
 
 Let's consider the following example, which defines 3 stages:
-```
+
+```yaml
 stages:
   - build
   - test
@@ -86,21 +101,26 @@ stages:
 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 any of the previous jobs fails, the commit is marked as `failed` and no jobs of further stage are executed.
+1. If any of the previous jobs fails, the commit is marked as `failed` and no
+   jobs of further stage are executed.
 
 There are also two edge cases worth mentioning:
 
-1. If no `stages` is defined in `.gitlab-ci.yml`, then by default the `build`, `test` and `deploy` are allowed to be used as job's stage by default.
+1. If no `stages` is defined in `.gitlab-ci.yml`, then by default the `build`,
+   `test` and `deploy` are allowed to be used as job's stage by default.
 2. If a job doesn't specify `stage`, the job is assigned the `test` stage.
 
 ### types
+
 Alias for [stages](#stages).
 
 ### variables
-**This feature requires `gitlab-runner` with version equal or greater than 0.5.0.**
 
-GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in build environment.
-The variables are stored in repository and are meant to store non-sensitive project configuration, ie. RAILS_ENV or DATABASE_URL.
+_**Note:** Introduced in GitLab Runner v0.5.0._
+
+GitLab CI allows you to add to `.gitlab-ci.yml` variables that are set in build
+environment. The variables are stored in the git repository and are meant to
+store non-sensitive project configuration, for example:
 
 ```yaml
 variables:
@@ -109,18 +129,23 @@ variables:
 
 These variables can be later used in all executed commands and scripts.
 
-The YAML-defined variables are also set to all created service containers, thus allowing to fine tune them.
+The YAML-defined variables are also set to all created service containers,
+thus allowing to fine tune them.
 
 ### cache
-`cache` is used to specify list of files and directories which should be cached between builds.
-Caches are stored according to the branch/ref and the job name. Caches are not
-currently shared between different job names or between branches/refs. This means
-caching will benefit you if you push subsequent commits to an existing feature branch.
 
-**The global setting allows to specify default cached files for all jobs.**
+`cache` is used to specify a list of files and directories which should be
+cached between builds. Caches are stored according to the branch/ref and the
+job name. They are not currently shared between different job names or between
+branches/refs, which means that caching will benefit you if you push subsequent
+commits to an existing feature branch.
+
+If `cache` is defined outside the scope of the jobs, it means it is set
+globally and all jobs will use its definition.
 
 To cache all git untracked files and files in `binaries`:
-```
+
+```yaml
 cache:
   untracked: true
   paths:
@@ -128,9 +153,10 @@ cache:
 ```
 
 ## Jobs
-`.gitlab-ci.yml` allows you to specify an unlimited number of jobs.
-Each job has to have a unique `job_name`, which is not one of the keywords mentioned above.
-A job is defined by a list of parameters that define the build behaviour.
+
+`.gitlab-ci.yml` allows you to specify an unlimited number of jobs. Each job
+must have a unique name, which is not one of the Keywords mentioned above.
+A job is defined by a list of parameters that define the build behavior.
 
 ```yaml
 job_name:
@@ -148,21 +174,22 @@ job_name:
   allow_failure: true
 ```
 
-| keyword       | required | description |
+| Keyword       | Required | Description |
 |---------------|----------|-------------|
-| script        | required | Defines a shell script which is executed by runner |
-| stage         | optional (default: test) | Defines a build stage |
-| type          | optional | Alias for `stage` |
-| only          | optional | Defines a list of git refs for which build is created |
-| except        | optional | Defines a list of git refs for which build is not created |
-| tags          | optional | Defines a list of tags which are used to select runner |
-| allow_failure | optional | Allow build to fail. Failed build doesn't contribute to commit status |
-| when          | optional | Define when to run build. Can be `on_success`, `on_failure` or `always` |
-| artifacts     | optional | Define list build artifacts |
-| cache         | optional | Define list of files that should be cached between subsequent runs |
+| script        | yes | Defines a shell script which is executed by runner |
+| stage         | no (default: `test`) | Defines a build stage |
+| 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 |
+| 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` |
+| artifacts     | no | Define list build artifacts |
+| cache         | no | Define list of files that should be cached between subsequent runs |
 
 ### script
-`script` is a shell script which is executed by runner. The shell script is prepended with `before_script`.
+
+`script` is a shell script which is executed by the runner. For example:
 
 ```yaml
 job:
@@ -170,6 +197,7 @@ job:
 ```
 
 This parameter can also contain several commands using an array:
+
 ```yaml
 job:
   script:
@@ -178,31 +206,45 @@ job:
 ```
 
 ### stage
-`stage` allows to group build into different stages. Builds of the same `stage` are executed in `parallel`.
-For more info about the use of `stage` please check the [stages](#stages).
+
+`stage` allows to group build into different stages. Builds of the same `stage`
+are executed in `parallel`. For more info about the use of `stage` please check
+[stages](#stages).
 
 ### only and except
-This are two parameters that allow for setting a refs policy to limit when jobs are built:
-1. `only` defines the names of branches and tags for which job will be built.
-2. `except` defines the names of branches and tags for which the job wil **not** be built.
 
-There are a few rules that apply to usage of refs policy:
+`only` and `except` are two parameters that set a refs policy to limit when
+jobs are built:
+
+1. `only` defines the names of branches and tags for which the job will be
+    built.
+2. `except` defines the names of branches and tags for which the job will
+    **not** be built.
+
+There are a few rules that apply to the usage of refs policy:
+
+* `only` and `except` are inclusive. If both `only` and `except` are defined
+   in a job specification, the ref is filtered by `only` and `except`.
+* `only` and `except` allow the use of regular expressions.
+* `only` and `except` allow the use of special keywords: `branches` and `tags`.
+* `only` and `except` allow to specify a repository path to filter jobs for
+   forks.
 
-1. `only` and `except` are inclusive. If both `only` and `except` are defined in job specification the ref is filtered by `only` and `except`.
-1. `only` and `except` allow for using the regexp expressions.
-1. `only` and `except` allow for using special keywords: `branches` and `tags`.
-These names can be used for example to exclude all tags and all branches.
+In the example below, `job` will run only for refs that start with `issue-`,
+whereas all branches will be skipped.
 
 ```yaml
 job:
+  # use regexp
   only:
-    - /^issue-.*$/ # use regexp
+    - /^issue-.*$/
+  # use special keyword
   except:
-    - branches # use special keyword
+    - branches
 ```
 
-1. `only` and `except` allow for specify repository path to filter jobs for forks.
-The repository path can be used to have jobs executed only for parent repository.
+The repository path can be used to have jobs executed only for the parent
+repository and not forks:
 
 ```yaml
 job:
@@ -211,33 +253,47 @@ job:
   except:
     - master@gitlab-org/gitlab-ce
 ```
-The above will run `job` for all branches on `gitlab-org/gitlab-ce`, except master .
+
+The above example will run `job` for all branches on `gitlab-org/gitlab-ce`,
+except master.
 
 ### tags
-`tags` is used to select specific runners from the list of all runners that are allowed to run this project.
 
-During registration of a runner, you can specify the runner's tags, ie.: `ruby`, `postgres`, `development`.
-`tags` allow you to run builds with runners that have the specified tags assigned:
+`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
+example `ruby`, `postgres`, `development`.
+
+`tags` allow you to run builds with runners that have the specified tags
+assigned to them:
+
+```yaml
 job:
   tags:
     - ruby
     - postgres
 ```
 
-The above specification will make sure that `job` is built by a runner that have `ruby` AND `postgres` tags defined.
+The specification above, will make sure that `job` is built by a runner that
+has both `ruby` AND `postgres` tags defined.
 
 ### when
-`when` is used to implement jobs that are run in case of failure or despite the failure.
+
+`when` is used to implement jobs that are run in case of failure or despite the
+failure.
 
 `when` can be set to one of the following values:
 
-1. `on_success` - execute build only when all builds from prior stages succeeded. This is the default.
-1. `on_failure` - execute build only when at least one build from prior stages failed.
+1. `on_success` - execute build only when all builds from prior stages
+    succeeded. This is the default.
+1. `on_failure` - execute build only when at least one build from prior stages
+    failed.
 1. `always` - execute build despite the status of builds from prior stages.
 
-```
+For example:
+
+```yaml
 stages:
 - build
 - cleanup_build
@@ -245,28 +301,28 @@ stages:
 - deploy
 - cleanup
 
-build:
+build_job:
   stage: build
   script:
   - make build
 
-cleanup_build:
+cleanup_build_job:
   stage: cleanup_build
   script:
   - cleanup build when failed
   when: on_failure
 
-test:
+test_job:
   stage: test
   script:
   - make test
 
-deploy:
+deploy_job:
   stage: deploy
   script:
   - make deploy
 
-cleanup:
+cleanup_job:
   stage: cleanup
   script:
   - cleanup after builds
@@ -274,84 +330,107 @@ cleanup:
 ```
 
 The above script will:
-1. Execute `cleanup_build` only when the `build` failed,
-2. Always execute `cleanup` as the last step in pipeline.
+
+1. Execute `cleanup_build_job` only when `build_job` fails
+2. Always execute `cleanup_job` as the last step in pipeline.
 
 ### artifacts
-`artifacts` is used to specify list of files and directories which should be attached to build after success.
 
-1. Send all files in `binaries` and `.config`:
+_**Note:** Introduced in GitLab Runner v0.7.0._
+
+`artifacts` is used to specify list of files and directories which should be
+attached to build after success. Below are some examples.
 
-        artifacts:
+Send all files in `binaries` and `.config`:
+
+```yaml
+artifacts:
   paths:
   - binaries/
   - .config
+```
 
-2. Send all git untracked files:
+Send all git untracked files:
 
-        artifacts:
+```yaml
+artifacts:
   untracked: true
+```
 
-3. Send all git untracked files and files in `binaries`:
+Send all git untracked files and files in `binaries`:
 
-        artifacts:
+```yaml
+artifacts:
   untracked: true
   paths:
   - binaries/
+```
 
-The artifacts will be send after the build success to GitLab and will be accessible in GitLab interface to download.
-
-This feature requires GitLab Runner v0.7.0 or higher.
+The artifacts will be send after a successful build success to GitLab, and will
+be accessible in the GitLab UI to download.
 
 ### cache
-`cache` is used to specify list of files and directories which should be cached between builds.
 
-1. Cache all files in `binaries` and `.config`:
+_**Note:** Introduced in GitLab Runner v0.7.0._
+
+`cache` is used to specify list of files and directories which should be cached
+between builds. Below are some examples:
+
+Cache all files in `binaries` and `.config`:
 
-        rspec:
+```yaml
+rspec:
   script: test
   cache:
     paths:
     - binaries/
     - .config
+```
 
-2. Cache all git untracked files:
+Cache all git untracked files:
 
-        rspec:
+```yaml
+rspec:
   script: test
   cache:
     untracked: true
+```
 
-3. Cache all git untracked files and files in `binaries`:
+Cache all git untracked files and files in `binaries`:
 
-        rspec:
+```yaml
+rspec:
   script: test
   cache:
     untracked: true
     paths:
     - binaries/
+```
 
-4. Locally defined cache overwrites globally defined options. This will cache only `binaries/`:
+Locally defined cache overwrites globally defined options. This will cache only
+`binaries/`:
 
-        cache:
+```yaml
+cache:
   paths:
   - my/files
 
-        rspec:
+rspec:
   script: test
   cache:
     paths:
     - binaries/
+```
 
-The cache is provided on best effort basis, so don't expect that cache will be present.
-For implementation details please check GitLab Runner.
-
-This feature requires GitLab Runner v0.7.0 or higher.
-
+The cache is provided on best effort basis, so don't expect that cache will be
+always present. For implementation details please check GitLab Runner.
 
 ## Validate the .gitlab-ci.yml
+
 Each instance of GitLab CI has an embedded debug tool called Lint.
-You can find the link to the Lint in the project's settings page or use short url `/lint`.
+You can find the link under `/ci/lint` of your gitlab instance.
 
 ## Skipping builds
-There is one more way to skip all builds, if your commit message contains tag [ci skip]. In this case, commit will be created but builds will be skipped
+
+If your commit message contains `[ci skip]`, the commit will be created but the
+builds will be skipped.

doc/install/installation.md

@@ -348,7 +348,7 @@ GitLab Shell is an SSH access and repository management software developed speci
     cd /home/git
     sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-workhorse.git
     cd gitlab-workhorse
-    sudo -u git -H git checkout 0.5.0
+    sudo -u git -H git checkout 0.5.1
     sudo -u git -H make
 
 ### Initialize Database and Activate Advanced Features

doc/update/8.2-to-8.3.md

@@ -67,7 +67,7 @@ sudo -u git -H git checkout 8-3-stable-ee
 ```bash
 cd /home/git/gitlab-shell
 sudo -u git -H git fetch --all
-sudo -u git -H git checkout v2.6.8
+sudo -u git -H git checkout v2.6.9
 ```
 
 ### 5. Update gitlab-workhorse
@@ -78,7 +78,7 @@ which should already be on your system from GitLab 8.1.
 ```bash
 cd /home/git/gitlab-workhorse
 sudo -u git -H git fetch --all
-sudo -u git -H git checkout 0.5.0
+sudo -u git -H git checkout 0.5.1
 sudo -u git -H make
 ```
 

features/steps/project/forked_merge_requests.rb

@@ -41,7 +41,8 @@ class Spinach::Features::ProjectForkedMergeRequests < Spinach::FeatureSteps
 
     click_button "Compare branches and continue"
 
-    expect(page).to have_content "New Merge Request"
+    expect(page).to have_css("h3.page-title", text: "New Merge Request")
+
     fill_in "merge_request_title", with: "Merge Request On Forked Project"
   end
 

features/steps/shared/diff_note.rb

@@ -166,7 +166,7 @@ module SharedDiffNote
   end
 
   step 'I should see add a diff comment button' do
-    expect(page).to have_css('.js-add-diff-note-button', visible: true)
+    expect(page).to have_css('.js-add-diff-note-button')
   end
 
   step 'I should see an empty diff comment form' do

lib/api/entities.rb

@@ -70,7 +70,7 @@ module API
       expose :forked_from_project, using: Entities::ForkedFromProject, if: lambda{ |project, options| project.forked? }
       expose :avatar_url
       expose :star_count, :forks_count
-      expose :open_issues_count, if: lambda { | project, options | project.issues_enabled? && project.default_issues_tracker? }
+      expose :open_issues_count, if: lambda { |project, options| project.issues_enabled? && project.default_issues_tracker? }
     end
 
     class ProjectMember < UserBasic

lib/api/projects.rb

@@ -39,6 +39,17 @@ module API
         present @projects, with: Entities::Project
       end
 
+      # Gets starred project for the authenticated user
+      #
+      # Example Request:
+      #   GET /projects/starred
+      get '/starred' do
+        @projects = current_user.starred_projects
+        @projects = filter_projects(@projects)
+        @projects = paginate @projects
+        present @projects, with: Entities::Project
+      end
+
       # Get all projects for admin user
       #
       # Example Request:

spec/features/merge_requests/merge_when_build_succeeds_spec.rb

@@ -21,12 +21,12 @@ feature 'Merge When Build Succeeds', feature: true, js: true do
     end
 
     it 'displays the Merge When Build Succeeds button' do
-      expect(page).to have_link "Merge When Build Succeeds"
+      expect(page).to have_button "Merge When Build Succeeds"
     end
 
     context "Merge When Build succeeds enabled" do
       before do
-        click_link "Merge When Build Succeeds"
+        click_button "Merge When Build Succeeds"
       end
 
       it 'activates Merge When Build Succeeds feature' do
@@ -58,7 +58,7 @@ feature 'Merge When Build Succeeds', feature: true, js: true do
     it 'cancels the automatic merge' do
       click_link "Cancel Automatic Merge"
 
-      expect(page).to have_link  "Merge When Build Succeeds"
+      expect(page).to have_button "Merge When Build Succeeds"
 
       visit_merge_request(merge_request) # Needed to refresh the page
       expect(page).to have_content "Canceled the automatic merge"

spec/requests/api/projects_spec.rb

@@ -139,6 +139,25 @@ describe API::API, api: true  do
     end
   end
 
+  describe 'GET /projects/starred' do
+    before do
+      admin.starred_projects << project
+      admin.save!
+    end
+
+    it 'should return the starred projects' do
+      get api('/projects/all', admin)
+      expect(response.status).to eq(200)
+      expect(json_response).to be_an Array
+
+      expect(json_response).to satisfy do |response|
+        response.one? do |entry|
+          entry['name'] == project.name
+        end
+      end
+    end
+  end
+
   describe 'POST /projects' do
     context 'maximum number of projects reached' do
       it 'should not create new project and respond with 403' do
@@ -471,7 +490,7 @@ describe API::API, api: true  do
     end
   end
 
-  describe 'PUT /projects/:id/snippets/:shippet_id' do
+  describe 'PUT /projects/:id/snippets/:snippet_id' do
     it 'should update an existing project snippet' do
       put api("/projects/#{project.id}/snippets/#{snippet.id}", user),
         code: 'updated code'