[SERVER-49164] Sweep for and fix missing dependencies in evergreen.yml Created: 29/Jun/20  Updated: 29/Oct/23  Resolved: 03/Sep/20

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: 4.7.0

Type: Improvement Priority: Major - P3
Reporter: Ian Whalen (Inactive) Assignee: Robert Guo (Inactive)
Resolution: Fixed Votes: 0
Labels: tig-evgconfig
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: STM 2020-08-24, STM 2020-09-07
Participants:
Story Points: 0

 Description   

We just noticed that some tasks (like "jscore txns large txns format") are dependent on compile when it probably makes more sense to have them depend on jscore?

https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_62_64_bit_dynamic_required_jsCore_txns_large_txns_format_3ea60282c8841c67d4e2f3a365b7f1640c84198c_20_06_29_14_07_33

While at it, it seems like someone should just do a one-time sweep and see if there's any other dependencies it would make sense to add.

I know this doesn't fit perfectly with the STM charter, but TBH it probably doesn't fit well with anyone's charter, and this seems like the cleanest fit?

CC pasette



 Comments   
Comment by Githook User [ 27/Aug/20 ]

Author:

{'name': 'Robert Guo', 'email': 'robert.guo@10gen.com', 'username': 'guoyr'}

Message: SERVER-49164 fix missing task dependencies in evergreen.yml
Branch: master
https://github.com/mongodb/mongo/commit/a730122e5b98e872c2634d5b04d27933e1cc0f3d

Comment by Ian Whalen (Inactive) [ 20/Aug/20 ]

woot ty robert! I know this kind of cleanup isn't the most exciting but I do think it's very valuable to take care of this kind of cruft every few years!

Comment by Brooke Miller [ 30/Jun/20 ]

We discussed in Story Pointing that we should timebox this exercise to 2 hours.

Comment by Daniel Pasette (Inactive) [ 29/Jun/20 ]

the general case we observe is that if the base suite fails, the passthrough suite fails. This leads to an explosion of duplicate tickets that burdens the build baron team and wastes resources and reduces signal to noise. I think we should solve for the general case.

Comment by Ian Whalen (Inactive) [ 29/Jun/20 ]

got it. I'll leave it to pasette to think on it.

Comment by Andrew Morrow (Inactive) [ 29/Jun/20 ]

ian.whalen - I'm not sure that it is necessarily true that we want jsCore variants to depend on jsCore. In the past, we had complex dependency trees in the test suites. The result was that test suites that had dependencies on other test suites simply didn't run if the base suite started to fail. When the base suite was repaired, suddenly we would find that the depending suite now had new error modes that had been unobservable during the period where the base suite was broken. Another thing to consider is that jsCore might have a failure related to an introduced defect, but the jsCore variant could fail in additional ways, but with the same root cause. Without the additional information gleaned from observing the effect of the defect in the jsCore variant, we could end up committing an incomplete "fix" for the issue as apparently understood only from the observed mode of failure in jsCore.

Generated at Thu Feb 08 05:19:06 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.