Skip to content

Fix previous deployment fetches wrong deployment

Shinya Maeda requested to merge fix-previous-deployment into master

What does this MR do?

While we were investigating #321032 (closed), we realized that the previous_deployment method actually doesn't return the previous deployment. It actually returns the other-but-latest deployment.

This MR fixes the outstanding issue.

Related #321032 (closed)

Query Performance implication

!58567 (comment 545092453)

@mattkasa That's good question. This change actually also optimizes the query performance.

Here is the current plan:

 Limit  (cost=0.57..4.45 rows=1 width=139) (actual time=8.236..8.238 rows=0 loops=1)
   Buffers: shared read=4
   I/O Timings: read=8.181
   ->  Index Scan using index_deployments_on_environment_id_and_id on public.deployments  (cost=0.57..667.53 rows=172 width=139) (actual time=8.233..8.234 rows=0 loops=1)
         Index Cond: (deployments.environment_id = 39)
         Filter: ((deployments.id <> 124) AND ((deployments.ref)::text = 'master'::text))
         Rows Removed by Filter: 0
         Buffers: shared read=4
         I/O Timings: read=8.181

and here is the new plan:

 Limit  (cost=0.57..3.59 rows=1 width=139) (actual time=8.884..8.885 rows=0 loops=1)
   Buffers: shared hit=3 read=4
   I/O Timings: read=8.755
   ->  Index Scan using index_deployments_on_environment_id_status_and_id on public.deployments  (cost=0.57..3.59 rows=1 width=139) (actual time=8.881..8.881 rows=0 loops=1)
         Index Cond: ((deployments.environment_id = 39) AND (deployments.status = 2) AND (deployments.id < 124))
         Buffers: shared hit=3 read=4
         I/O Timings: read=8.755

Notice that Filter: ((deployments.id <> 124) AND ((deployments.ref)::text = 'master'::text)) is quite expensive that likely takes long time when an environment has a lot of deployments. This is because we don't have effective index on the ref column.

The new plan performs one index scan with index_deployments_on_environment_id_status_and_id and doesn't perform any sequential filtering. This assures that the query will stay performant regardless of the deployments count on an environment.

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Mayra Cabrera

Merge request reports