Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build Tooling: Increase number of Travis E2E test jobs #15228

Merged
merged 1 commit into from
Apr 29, 2019

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 noisysocks, gziolo 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.

3 participants