[SERVER-46130] Benchmarks archiving isn't using hygienic targets Created: 13/Feb/20  Updated: 28/Aug/23  Resolved: 28/Aug/23

Status: Closed
Project: Core Server
Component/s: Build
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Server Development Platform
Participants:

 Description   

See https://github.com/mongodb/mongo/blob/12b63497b80c46f31cb1ece3a23887e50a129504/etc/evergreen.yml#L4322-L4350

We should be using the archive-benchmarks target to produce a tarball of runnable benchmarks.



 Comments   
Comment by Mathew Robinson (Inactive) [ 18/Feb/20 ]

Yes this should go to Self-Testable Installs.

Resmoke does not support configurable paths for the test txt files so even if we auto installed it we wouldn't get anything resmoke could use.

You could still use the archive target for the binaries only and ship the txt file using the existing mechanism. This would be similar to what we do with artifacts.tgz and dist-test now for compile.

Comment by Andrew Morrow (Inactive) [ 16/Feb/20 ]

mathew.robinson - I was taking a look at this, and I found a bit of a wrinkle. We don't include the test list in the test archives! So if you build archive-benchmarks you do get a package of benchmark binaries out of it, but it doesn't include benchmarks.txt. And since the execution of the benchmarks is expected to happen on a remote machine, we can't just use the benchmarks.txt that got generated locally. A first step at fixing it would probably be to AutoInstall the result of env.TestList in mongo_benchmarks.py , but that raises other questions. To where should benchmarks.txt be installed? And the paths that it has are probably incorrect. This may not be something we can fix until we get to self-testable installs? Maybe we should move this ticket there, at least for now? It doesn't seem likely that we are going to be able to just fix this with the setup we have now.

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