tree 12466d2236e6fcab6ffc3d0cbd4ad004ce5597cd
parent 23f1896a267425f920cd24d5f63ea080db75e0c7
author Marco Miller <marco.miller@ericsson.com> 1592426919 -0400
committer Marco Miller <marco.miller@ericsson.com> 1592431620 -0400

CreateChangesTriggeringGc: Support existing project

Add a CreateChangesTriggeringGcWithProject scenario that wraps the
CreateChangesTriggeringGc scenario. Do so for the latter to run without
creating its own project anymore. This way, have a scenario that creates
its own project (and deletes it after) still, plus one that doesn't.

This is so that it becomes possible to run the CreateChangesTriggeringGc
scenario with a pre-configured test project. Say, for jgit client
testing purposes in gc-executor, such as changing core.trustfolderstat
and comparing the resulting gc completion times. Local testing showed
roughly doubling gc completion times when changing trustfolderstat to
false, for example.

For the CheckProjectStatisticsUpToGc scenario step to end up reporting
OKs in that trustfolderstat=false case, double its allotted
MaxSecondsForGcToComplete time. This only makes the step or scenario
last 10 seconds longer in other cases.

Make some CreateChangesTriggeringGc fields accessible from a so reusing
scenario, here by CreateChangesTriggeringGcWithProject.

Make CreateChangesTriggeringGc a ProjectSimulation, now that its test
PROJECT name comes either from the aggregating scenario or the execution
environment. Before this change, that project name was automatically
generated, i.e., set to that scenario's class name by default.

Change-Id: I035e32e52fec85b21699a6963be392e5a3639d27