-
Notifications
You must be signed in to change notification settings - Fork 2k
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
ETK: Use artifact dependency from API #50966
Conversation
This PR does not affect the size of JS and CSS bundles shipped to the user's browser. Generated by performance advisor bot at iscalypsofastyet.com. |
2ad1134
to
ebceb62
Compare
In the first build, we can see that it was not tagged as different from trunk. After pushing a change which modifies the build, we see that it does get tagged properly. This means that the diff functionality is still working. (the build number matches the latest tagged build on trunk) |
Phpunit failing due to WordPress/gutenberg#29752 |
3aaee06
to
6425bf4
Compare
6425bf4
to
48df4f4
Compare
I'm going to merge this to test out the ETK build on trunk. Will keep an eye on it to make sure everything works as expected. Unfortunately, that's the only way to verify this fix works, but thankfully this is a low-impact change. |
Changes proposed in this Pull Request
We use the artifact of the previous "tagged" build on trunk to determine when the current build has modified ETK. A limitation of the artifact dependency feature is that it downloads the artifact at the start of the build. As a result, the previous ETK build must be completely finished before the current build starts, or we might accidentally tag a commit as "changing ETK". (This happens when commit A changes ETK, and commit B does not, but both A and B are merged within a couple minutes of each other. Since A and B run in parallel, B cannot rely on the artifact from A. So it will diff its build (which includes commit A because of git history) against the exact same artifact A is going to diff against. As a result, both commits get tagged as "changing" ETK.)
This approach will download the artifact from the API instead of from the artifact dependency feature. This means that in the scenario above, build A would have to finish by the time the "process artifact" step of build B begins. Since that step is only a few seconds long, and is the last in the build, both builds A and B can run in parallel for almost all of the build.
Practically, this means that the window where this bug can occur will be reduced from
$length_of_build
to$length_of_step
. Which is effectively from a few minutes down to a few seconds.I think this change will reduce the number of times the bug will happen, which will open the door to Slack notifications on changed builds.
Testing instructions
Test tagged commit: