On 14 Aug, Javier Pena wrote: > Two months after this e-mail, we're having the same situation.
Looking at the example patch you used before, (which hasn't merged yet) I see this as a combination of factors: On one side, the fact that we are launching jobs that would not be affected by the patch. This increase the number of jobs on a single run. In these cases even without a permanent solution I tend to create a temporary patch for CI that removes every job and runs the only one I need, and make my patch depend on it. On the other side, there's our excessive reliance on end-to-end integration tests (when we deploy everything to test our code, we also have to collect everything). Because of the poor execution paths coverage we are getting from these kind of tests we tend to err on the side of caution and add several integration tests to be sure we're not breaking any other execution path. This also increases the number of rechecks needed, as we take more time and resources to discover that a PS has broken an execution path. Shifting our strategy to use more functional test would help in this case. It would be interesting to gather statistics on what repos trigger the most jobs, and see where we could start reducing. _______________________________________________ dev mailing list email@example.com http://lists.rdoproject.org/mailman/listinfo/dev To unsubscribe: dev-unsubscr...@lists.rdoproject.org