Skip to content

Proactively marking MRs in train as stale

Shinya Maeda requested to merge support-squash-merge-in-merge-train into master

Important: This feature will be announced in gitlab-com/www-gitlab-com!36507 (merged). This MR has to be merged by Friday.

What does this MR do?

This MR avoids stale pipelines detection via git commit history, but instead proactively marking merge request as stale if a certain event happens.

For example, when

  • A merge request is dropped from a merge train
  • A target branch is out of merge train cycle (e.g. Immediate merge was processed)

In those cases, an MR (technically, a metadata belongs to MR) will be marked as stale status. Sidekiq will refresh the merge request on train later.

This resolves core problems on merge train that:

  • Merge Train doesn't support squash and merge (The main problem to solve)
  • Merge Train doesn't support FF-merge
  • Merge Train is not immediately refreshed when master is advanced

Close #13001 (closed) #12971 (closed)

Feature Flag

This feature is implemented behind merge_train_new_stale_check feature flag and enabled by default. Once we've confirmed the feature is deemed stable, we remove the feature flag.

Manual QA

Date: Tue Dec 10 06:37:07 UTC 2019

Case: MR with sqush merge option

Steps:

  1. Add MR1 to a train with squash merge option
  2. Add MR2 to a train with squash merge option
  3. Finish pipeline for MR2
  4. Finish pipeline for MR1

Expectations:

  • MR1 is squashed and merged
  • MR2 is squashed and merged

**Result: PASS ✔ **

Case: master is advanced

Steps:

  1. Add MR1 to a train
  2. Add MR2 to a train
  3. Merge MR3 immediately into master

Expectations:

  • MR1 re-creates pipeline for merge train
  • MR2 re-creates pipeline for merge train

**Result: PASS ✔ **

Merge Train status explanation

  • created means the merge request is on merge train and has not started pipeline yet.
  • fresh means the merge request is on merge train and has started pipeline.
  • stale means the merge request is on merge train but its combined ref is stale, thus pipeline recreation is needed.
  • merged means the merge request was on merge train and has been merged already.

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 Shinya Maeda

Merge request reports