Skip to content

Conversation

@aduth
Copy link
Member

@aduth aduth commented Apr 26, 2019

Related: #15159, #14289 (comment)

This pull request seeks to double the number of Travis jobs dedicated to running end-to-end tests. In other words, it distributes the number of tests across 4 containers (vs. 2 previously) for each of the "Admin with plugins" and "Author without plugins" variations.

The desired effect here is that the total duration of a build decreases, since the number of end-to-end tests handled by any one Travis container will have lessened by a half.

To the potential question of whether "more containers" is okay or not, see also #14289 (comment) .

Testing Instructions:

Verify that the build passes.

@aduth aduth added [Type] Build Tooling Issues or PRs related to build tooling [Type] Performance Related to performance efforts labels Apr 26, 2019
@aduth aduth requested review from gziolo, noisysocks and ntwb April 26, 2019 18:50
@aduth aduth mentioned this pull request Apr 26, 2019
14 tasks
@aduth
Copy link
Member Author

aduth commented Apr 26, 2019

Evaluating the result, it's an improvement, though not to the extent I might have hoped.

Comparing:

The longest job decreases from 12m55s to 10m3s (22% decrease).

The likely explanation here is that we'll encounter diminishing returns on the basis there is a common overhead amongst all these jobs: npm install and npm run build. As noted in #15159, this could be alleviated by pre-generating the build to be used across containers.

That all being said, an improvement is an improvement, and I still think it'd be worthwhile to move forward with this change.

@gziolo
Copy link
Member

gziolo commented Apr 29, 2019

The likely explanation here is that we'll encounter diminishing returns on the basis there is a common overhead amongst all these jobs: npm install and npm run build. As noted in #15159, this could be alleviated by pre-generating the build to be used across containers.

We also should look into how to optimize for Travis the usage of cross-env SCRIPT_DEBUG=false ./bin/reset-e2e-tests.sh. It seems like it might be a part of ./bin/setup-local-env.js since you never re-run the same job without starting Docker from scratch.

It might have a large impact on the duration of each job as well.

Copy link
Member

@gziolo gziolo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's give it a go and see how it works in action. As noted, we should also look into other optimizations in parallel.

@aduth
Copy link
Member Author

aduth commented Apr 29, 2019

We also should look into how to optimize for Travis the usage of cross-env SCRIPT_DEBUG=false ./bin/reset-e2e-tests.sh. It seems like it might be a part of ./bin/setup-local-env.js since you never re-run the same job without starting Docker from scratch.

That's a good point. I'd mentioned something similar before in my "aside" of #14245 (comment). I'll make a note of this in the parent issue #15159.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Type] Build Tooling Issues or PRs related to build tooling [Type] Performance Related to performance efforts

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants