[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 |
|
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. |