Merge branch 'master' into droplab-templating-xss-fix

changelogs/unreleased/tc-realtime-every-pipeline-on-mr.yml

+---
+title: Properly expire cache for all MRs of a pipeline
+merge_request: 10770
+author:

config/database.yml.mysql

@@ -25,6 +25,7 @@ development:
   pool: 5
   username: root
   password: "secure password"
+  # host: localhost
   # socket: /tmp/mysql.sock
 # Warning: The database defined as "test" will be erased and
@@ -39,4 +40,5 @@ test: &test
   pool: 5
   username: root
   password:
+  # host: localhost
   # socket: /tmp/mysql.sock

config/database.yml.postgresql

@@ -9,7 +9,7 @@ production:
   # username: git
   # password:
   # host: localhost
-  # port: 5432 
+  # port: 5432
 #
 # Development specific
@@ -21,6 +21,7 @@ development:
   pool: 5
   username: postgres
   password:
+  # host: localhost
 #
 # Staging specific
@@ -32,6 +33,7 @@ staging:
   pool: 5
   username: postgres
   password:
+  # host: localhost
 # Warning: The database defined as "test" will be erased and
 # re-generated from your development database when you run "rake".
@@ -43,3 +45,4 @@ test: &test
   pool: 5
   username: postgres
   password:
+  # host: localhost

config/gitlab.yml.example

@@ -505,6 +505,11 @@ production: &base
     # If you use non-standard ssh port you need to specify it
     # ssh_port: 22
+  workhorse:
+    # File that contains the secret key for verifying access for gitlab-workhorse.
+    # Default is '.gitlab_workhorse_secret' relative to Rails.root (i.e. root of the GitLab app).
+    # secret_file: /home/git/gitlab/.gitlab_workhorse_secret
+
   ## Git settings
   # CAUTION!
   # Use the default values unless you really know what you are doing

config/initializers/1_settings.rb

@@ -387,6 +387,12 @@ Settings.gitlab_shell['ssh_user']     ||= Settings.gitlab.user
 Settings.gitlab_shell['owner_group']  ||= Settings.gitlab.user
 Settings.gitlab_shell['ssh_path_prefix'] ||= Settings.__send__(:build_gitlab_shell_ssh_path_prefix)
+#
+# Workhorse
+#
+Settings['workhorse'] ||= Settingslogic.new({})
+Settings.workhorse['secret_file'] ||= Rails.root.join('.gitlab_workhorse_secret')
+
 #
 # Repositories
 #

config/initializers/rspec_profiling.rb

@@ -38,7 +38,7 @@ if Rails.env.test?
     end
   end
-  if ENV.has_key?('CI')
+  if ENV.has_key?('CI') && ENV['GITLAB_DATABASE'] == 'postgresql'
     RspecProfiling::VCS::Git.prepend(RspecProfilingExt::Git)
     RspecProfiling::Run.prepend(RspecProfilingExt::Run)
   end

db/migrate/20170423064036_add_index_on_ci_builds_updated_at.rb

+# See http://doc.gitlab.com/ce/development/migration_style_guide.html
+# for more information on how to write migrations for GitLab.
+
+class AddIndexOnCiBuildsUpdatedAt < ActiveRecord::Migration
+  include Gitlab::Database::MigrationHelpers
+
+  # Set this constant to true if this migration requires downtime.
+  DOWNTIME = false
+
+  disable_ddl_transaction!
+
+  def up
+    add_concurrent_index :ci_builds, :updated_at
+  end
+
+  def down
+    remove_concurrent_index :ci_builds, :updated_at if index_exists?(:ci_builds, :updated_at)
+  end
+end

db/schema.rb

@@ -11,7 +11,7 @@
 #
 # It's strongly recommended that you check this file into your version control system.
-ActiveRecord::Schema.define(version: 20170419001229) do
+ActiveRecord::Schema.define(version: 20170423064036) do
   # These are extensions that must be enabled in order to support this database
   enable_extension "plpgsql"
@@ -241,6 +241,7 @@ ActiveRecord::Schema.define(version: 20170419001229) do
   add_index "ci_builds", ["status", "type", "runner_id"], name: "index_ci_builds_on_status_and_type_and_runner_id", using: :btree
   add_index "ci_builds", ["status"], name: "index_ci_builds_on_status", using: :btree
   add_index "ci_builds", ["token"], name: "index_ci_builds_on_token", unique: true, using: :btree
+  add_index "ci_builds", ["updated_at"], name: "index_ci_builds_on_updated_at", using: :btree
   create_table "ci_pipelines", force: :cascade do |t|
     t.string "ref"

doc/administration/gitaly/index.md

 # Gitaly
-[Gitaly](https://gitlab.com/gitlab-org/gitlay) (introduced in GitLab
+[Gitaly](https://gitlab.com/gitlab-org/gitaly) (introduced in GitLab
 9.0) is a service that provides high-level RPC access to Git
 repositories. As of GitLab 9.1 it is still an optional component with
 limited scope.

doc/api/jobs.md

@@ -120,7 +120,7 @@ Example of response
 Get a list of jobs for a pipeline.
 ```
-GET /projects/:id/pipeline/:pipeline_id/jobs
+GET /projects/:id/pipelines/:pipeline_id/jobs
 ```
 | Attribute     | Type                           | Required | Description          |

doc/api/projects.md

@@ -859,6 +859,17 @@ Parameters:
 | `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) |
 | `file` | string | yes | The file to be uploaded |
+To upload a file from your filesystem, use the `--form` argument. This causes
+cURL to post data using the header `Content-Type: multipart/form-data`.
+The `file=` parameter must point to a file on your filesystem and be preceded
+by `@`. For example:
+
+```bash
+curl --request POST --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" --form "file=@dk.png" https://gitlab.example.com/api/v3/projects/5/uploads
+```
+
+Returned object:
+
 ```json
 {
   "alt": "dk",
@@ -868,8 +879,8 @@ Parameters:
 ```
 **Note**: The returned `url` is relative to the project path.
-In Markdown contexts, the link is automatically expanded when the format in `markdown` is used.
-
+In Markdown contexts, the link is automatically expanded when the format in
+`markdown` is used.
 ## Project members

doc/development/fe_guide/index.md

@@ -75,7 +75,7 @@ sharing a Merge Request with a reviewer or a maintainer.
 1. Follow the steps in [Vue.js Best Practices](vue.md)
 1. Follow the style guide.
 1. Only a handful of people are allowed to merge Vue related features.
-Reach out to @jschatz, @iamphill, @fatihacet or @filipa early in this process.
+Reach out to one of Vue experts early in this process.
 ---

doc/install/installation.md

@@ -470,10 +470,8 @@ with setting up Gitaly until you upgrade to GitLab 9.2 or later.
     sudo chmod 0700 /home/git/gitlab/tmp/sockets/private
     sudo chown git /home/git/gitlab/tmp/sockets/private
-    # Configure Gitaly
-    cd /home/git/gitaly
-    sudo -u git cp config.toml.example config.toml
     # If you are using non-default settings you need to update config.toml
+    cd /home/git/gitaly
     sudo -u git -H editor config.toml
     # Enable Gitaly in the init script

doc/update/9.0-to-9.1.md

@@ -317,6 +317,17 @@ the socket path, but with `unix:` in front.
 Each entry under `storages:` should use the same `gitaly_address`.
+#### Compile Gitaly
+
+This step will also create `config.toml.example` which you need below.
+
+```shell
+cd /home/git/gitaly
+sudo -u git -H git fetch --all --tags
+sudo -u git -H git checkout v$(</home/git/gitlab/GITALY_SERVER_VERSION)
+sudo -u git -H make
+```
+
 #### Gitaly config.toml
 In GitLab 9.1 we are replacing environment variables in Gitaly with a

doc/user/admin_area/monitoring/health_check.md

 # Health Check
-> [Introduced][ce-3888] in GitLab 8.8.
-
-GitLab provides a health check endpoint for uptime monitoring on the `health_check` web
-endpoint. The health check reports on the overall system status based on the status of
-the database connection, the state of the database migrations, and the ability to write
-and access the cache. This endpoint can be provided to uptime monitoring services like
-[Pingdom][pingdom], [Nagios][nagios-health], and [NewRelic][newrelic-health].
+>**Notes:**
+  - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1.
+  - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and will
+    be deprecated in GitLab 9.1. Read more in the [old behavior](#old-behavior)
+    section.
+
+GitLab provides liveness and readiness probes to indicate service health and
+reachability to required services. These probes report on the status of the
+database connection, Redis connection, and access to the filesystem. These
+endpoints [can be provided to schedulers like Kubernetes][kubernetes] to hold
+traffic until the system is ready or restart the container as needed.
 ## Access Token
-An access token needs to be provided while accessing the health check endpoint. The current
-accepted token can be found on the `admin/health_check` page of your GitLab instance.
+An access token needs to be provided while accessing the probe endpoints. The current
+accepted token can be found under the **Admin area ➔ Monitoring ➔ Health check**
+(`admin/health_check`) page of your GitLab instance.
 ![access token](img/health_check_token.png)
 The access token can be passed as a URL parameter:
 ```
-https://gitlab.example.com/health_check.json?token=ACCESS_TOKEN
+https://gitlab.example.com/-/readiness?token=ACCESS_TOKEN
 ```
-or as an HTTP header:
-```bash
-curl --header "TOKEN: ACCESS_TOKEN" https://gitlab.example.com/health_check.json
+which will then provide a report of system health in JSON format:
+```
+{
+  "db_check": {
+    "status": "ok"
+  },
+  "redis_check": {
+    "status": "ok"
+  },
+  "fs_shards_check": {
+    "status": "ok",
+    "labels": {
+      "shard": "default"
+    }
+  }
+}
 ```
 ## Using the Endpoint
-Once you have the access token, health information can be retrieved as plain text, JSON,
-or XML using the `health_check` endpoint:
+Once you have the access token, the probes can be accessed:
+
+- `https://gitlab.example.com/-/readiness?token=ACCESS_TOKEN`
+- `https://gitlab.example.com/-/liveness?token=ACCESS_TOKEN`
+
+## Status
+
+On failure, the endpoint will return a `500` HTTP status code. On success, the endpoint
+will return a valid successful HTTP status code, and a `success` message.
+
+## Old behavior
+
+>**Notes:**
+  - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1.
+  - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and will
+    be deprecated in GitLab 9.1. Read more in the [old behavior](#old-behavior)
+    section.
+
+GitLab provides a health check endpoint for uptime monitoring on the `health_check` web
+endpoint. The health check reports on the overall system status based on the status of
+the database connection, the state of the database migrations, and the ability to write
+and access the cache. This endpoint can be provided to uptime monitoring services like
+[Pingdom][pingdom], [Nagios][nagios-health], and [NewRelic][newrelic-health].
+
+Once you have the [access token](#access-token), health information can be
+retrieved as plain text, JSON, or XML using the `health_check` endpoint:
 - `https://gitlab.example.com/health_check?token=ACCESS_TOKEN`
 - `https://gitlab.example.com/health_check.json?token=ACCESS_TOKEN`
@@ -54,13 +96,13 @@ would be like:
 {"healthy":true,"message":"success"}
 ```
-## Status
-
 On failure, the endpoint will return a `500` HTTP status code. On success, the endpoint
 will return a valid successful HTTP status code, and a `success` message. Ideally your
 uptime monitoring should look for the success message.
+[ce-10416]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3888
 [ce-3888]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3888
 [pingdom]: https://www.pingdom.com
 [nagios-health]: https://nagios-plugins.org/doc/man/check_http.html
 [newrelic-health]: https://docs.newrelic.com/docs/alerts/alert-policies/downtime-alerts/availability-monitoring
+[kubernetes]: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

features/profile/profile.feature

@@ -60,7 +60,9 @@ Feature: Profile
     Then I should see a password error message
   Scenario: I visit history tab
-    Given I have activity
+    Given I logout
+    And I sign in via the UI
+    And I have activity
     When I visit Audit Log page
     Then I should see my activity

features/project/forked_merge_requests.feature

@@ -41,8 +41,7 @@ Feature: Project Forked Merge Requests
   @javascript
   Scenario: I see the users in the target project for a new merge request
-    Given I logout
-    And I sign in as an admin
+    Given I sign in as an admin
     And I have a project forked off of "Shop" called "Forked Shop"
     Then I visit project "Forked Shop" merge requests page
     And I click link "New Merge Request"

features/steps/project/forked_merge_requests.rb

@@ -6,7 +6,7 @@ class Spinach::Features::ProjectForkedMergeRequests < Spinach::FeatureSteps
   include Select2Helper
   step 'I am a member of project "Shop"' do
-    @project = Project.find_by(name: "Shop")
+    @project = ::Project.find_by(name: "Shop")
     @project ||= create(:project, :repository, name: "Shop")
     @project.team << [@user, :reporter]
   end

features/steps/project/merge_requests/acceptance.rb

@@ -43,7 +43,7 @@ class Spinach::Features::ProjectMergeRequestsAcceptance < Spinach::FeatureSteps
   end
   step 'I am signed in as a developer of the project' do
-    login_as(@user)
+    sign_in(@user)
   end
   step 'I should see merge request merged' do

features/steps/project/merge_requests/revert.rb

@@ -31,7 +31,7 @@ class Spinach::Features::RevertMergeRequests < Spinach::FeatureSteps
   step 'I am signed in as a developer of the project' do
     @user = create(:user) { |u| @project.add_developer(u) }
-    login_as(@user)
+    sign_in(@user)
   end
   step 'There is an open Merge Request' do