Proactively marking MRs in train as stale
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:
- Add MR1 to a train with squash merge option
- Add MR2 to a train with squash merge option
- Finish pipeline for MR2
- Finish pipeline for MR1
Expectations:
- MR1 is squashed and merged
- MR2 is squashed and merged
**Result: PASS
Case: master is advanced
Steps:
- Add MR1 to a train
- Add MR2 to a train
- 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
- [-] Changelog entry
- [-] Documentation created/updated or follow-up review issue created
-
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
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