Add latest changes from gitlab-org/gitlab@master

changelogs/unreleased/add-timestamps-to-api-pipelines-response.yml

+---
+title: Added timestamps (created_at and updated_at) to API pipelines response
+merge_request: 17911
+author:
+type: added

doc/api/pipelines.md

@@ -34,14 +34,18 @@ Example of response
     "status": "pending",
     "ref": "new-pipeline",
     "sha": "a91957a858320c0e17f3a0eca7cfacbff50ea29a",
-    "web_url": "https://example.com/foo/bar/pipelines/47"
+    "web_url": "https://example.com/foo/bar/pipelines/47",
+    "created_at": "2016-08-11T11:28:34.085Z",
+    "updated_at": "2016-08-11T11:32:35.169Z",
   },
   {
     "id": 48,
     "status": "pending",
     "ref": "new-pipeline",
     "sha": "eb94b618fb5865b26e80fdd8ae531b7a63ad851a",
-    "web_url": "https://example.com/foo/bar/pipelines/48"
+    "web_url": "https://example.com/foo/bar/pipelines/48",
+    "created_at": "2016-08-12T10:06:04.561Z",
+    "updated_at": "2016-08-12T10:09:56.223Z",
   }
 ]
 ```

doc/development/database_review.md

@@ -95,7 +95,7 @@ and details for a database reviewer:
   - Check queries timing (If any): Queries executed in a migration
     need to fit comfortably within `15s` - preferably much less than that - on GitLab.com.
 - Check [background migrations](background_migrations.md):
-  - Establish a time estimate for execution
+  - Establish a time estimate for execution on GitLab.com.
   - They should only be used when migrating data in larger tables.
     - If a single `update` is below than `1s` the query can be placed
       directly in a regular migration (inside `db/migrate`).
@@ -106,7 +106,11 @@ and details for a database reviewer:
     that post migrations are executed post-deployment in production.
 - Check [timing guidelines for migrations](#timing-guidelines-for-migrations)
 - Check migrations are reversible and implement a `#down` method
-- Data migrations should be reversible too or come with a description of how to reverse, when possible. This applies to all types of migrations (regular, post-deploy, background).
+- Check data migrations:
+  - Establish a time estimate for execution on GitLab.com.
+  - Depending on timing, data migrations can be placed on regular, post-deploy or background migrations.
+  - Data migrations should be reversible too or come with a description of how to reverse, when possible.
+    This applies to all types of migrations (regular, post-deploy, background).
 - Query performance
   - Check for any obviously complex queries and queries the author specifically
     points out for review (if any)

lib/api/entities.rb

@@ -682,6 +682,7 @@ module API
     class PipelineBasic < Grape::Entity
       expose :id, :sha, :ref, :status
+      expose :created_at, :updated_at
       expose :web_url do |pipeline, _options|
         Gitlab::Routing.url_helpers.project_pipeline_url(pipeline.project, pipeline)

spec/requests/api/pipelines_spec.rb

@@ -29,7 +29,7 @@ describe API::Pipelines do
         expect(json_response.first['sha']).to match /\A\h{40}\z/
         expect(json_response.first['id']).to eq pipeline.id
         expect(json_response.first['web_url']).to be_present
-        expect(json_response.first.keys).to contain_exactly(*%w[id sha ref status web_url])
+        expect(json_response.first.keys).to contain_exactly(*%w[id sha ref status web_url created_at updated_at])
       end
       context 'when parameter is passed' do