-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Enable revised output directory hash suffix computation #16910
Conversation
(There is a very unexpected integration test failure on Windows that I still have to debug) |
d9136dd
to
a40b6a0
Compare
Stacked on #16916, which fixes the pipeline. The change made a path to an Android tool slightly longer, which triggered a dormant bug in the Java launcher fixed by the linked PR. |
@meteorcloudy As explained in #14023 (comment), this change would be rather important for rules_go in order to support Go 1.20 (due February 2023). It also generally improves build times and reduces target graph sizes for transition-heavy builds. This flag only affects the Would it be possible to get a downstream pipeline for this change? It is currently stacked on #16916, which is a fix for an unrelated bug that caused Java tools to fail if their paths get too long (the flag flip can make paths slightly longer or shorter). |
@bazel-io flag |
Like #16916, I think we should cherry pick them in 6.1 |
A downstream test on this change is initiated here: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2765 Note that there are already some failures with Bazel@HEAD: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2764 (we're looking into fixing them) |
@bazel-io fork 6.1.0 |
a40b6a0
to
d9d640f
Compare
Downstream test failures on Windows such as this one may be a result of paths becoming longer as there are now two hash fragment in the exec configuration. @sdtwigg Given that the platform is already part of the ST hash (please correct me if I'm wrong here!), could we also flip |
0854b1c
to
5a56183
Compare
@sdtwigg I have also thought about this more and now feel that we should not cherry-pick this change. We haven't heard from rules_go users that they have seen their build times regress dramatically with Go 1.20 and as time passes, Bazel 7.0 comes closer and with it this commit. |
If we do not add this to 6.X, I do think we should submit this to 7.0. (I'm a bit lost as to whether that means this is fine as-is being merged into bazelbuild:master or if another branch is more appropriate.) |
It's fine to merge to master, Bazel 6.X releases are handled via the |
Flips `--experimental_output_directory_naming_scheme` and `--experimental_exec_configuration_distinguisher` to `diff_against_baseline` and `off`, respectively, which makes it so that Starlark transitions can return to previous configurations, thus improving cache hit rates. Also changes the fixed platform suffix in the exec configuration from an empty string to `"exec"` for compatibility with logic that looks for the substring `-exec-` in paths to determine whether the current configuration is the exec configuration. As a result of this commit, output directory paths can change in the following ways: * `-ST-<hash>` suffixes can change or disappear and, in rare cases, appear where they previously didn't * for exec configuration directories, `k8-opt-exec-2B5CBBC6` becomes `k8-opt-exec-ST-011b9bdc32ed` This may result in tool paths that are seven characters longer, which can cause builds on Windows to fail that were already very close to the `MAX_PATH` limit. A follow-up commit will reduce the length of the hash by three characters, bringing that increase down to four. Work towards bazelbuild#14023
16f3ecd
to
84f7911
Compare
@sdtwigg Just to make sure this isn't lost: If you want this PR to be merged, I think that you need to the |
@sdtwigg this is impacting us pretty badly, the recompiling of |
@com6056 what team do you represent? Is it possible to manually set these flags for your own builds? Did rules_go need any other updates to its own code in response to these changes? |
I'm at Mux (https://github.com/muxinc), and what flags would we have to set? Is it just these?
If so, ya we can totally just set those for now in our |
I would recommend setting only the first one for now. The second one may break some rulesets that rely on specific output path patterns to detect the exec configuration, which is fixed by the current PR. |
@gregestren @sdtwigg Friendly ping, is this in the process of being imported? Just want to make sure it hasn't gotten lost. |
@sdtwigg is still handling the import process. I last saw a code update from him earlier today. |
Any updates on this? And is there any chance we could get the fix for using |
Do you know which rulesets are known to break with the second one as it is currently implemented in Bazel 6.1.1? |
@sdtwigg is the import ready? |
I had approved the import internally but it looks like it breaks some tests
and so was not actually submitted. I was not re-added to the attention set
when this happened so I had just been assuming everything was proceeding
fine. Planning to look into those test breakages ASAP. I speculate it is
due to those tests hard-coding lookups to intermediate artifacts.
…On Wed, Apr 5, 2023 at 2:11 PM Greg ***@***.***> wrote:
@sdtwigg <https://github.com/sdtwigg> is the import ready?
—
Reply to this email directly, view it on GitHub
<#16910 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHX76DI5ZI53SNZ3FNXYADW7WYUHANCNFSM6AAAAAASSJ7BCQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@sdtwigg have been having some back and forth on the internal tests. I think he's pretty close to unblocking them. One of them is a shell test for path stripping. It assumed @fmeum we should export that test to GitHub. The only reason it's Google-internal is because only the Google executor has API support for path stripping before you changes, as you know. |
Flips `--experimental_output_directory_naming_scheme` and `--experimental_exec_configuration_distinguisher` to `diff_against_baseline` and `off`, respectively, which makes it so that Starlark transitions can return to previous configurations, thus improving cache hit rates. Also changes the fixed platform suffix in the exec configuration from an empty string to `"exec"` for compatibility with logic that looks for the substring `-exec-` in paths to determine whether the current configuration is the exec configuration. As a result of this commit, output directory paths can change in the following ways: * `-ST-<hash>` suffixes can change or disappear and, in rare cases, appear where they previously didn't * for exec configuration directories, `k8-opt-exec-2B5CBBC6` becomes `k8-opt-exec-ST-011b9bdc32ed` This may result in tool paths that are seven characters longer, which can cause builds on Windows to fail that were already very close to the `MAX_PATH` limit. A follow-up commit will reduce the length of the hash by three characters, bringing that increase down to four. Work towards bazelbuild#14023 Closes bazelbuild#16910. PiperOrigin-RevId: 523999034 Change-Id: Id5548a00b62ebfe7889cd40177995210ecc224c1
Flips `--experimental_output_directory_naming_scheme` and `--experimental_exec_configuration_distinguisher` to `diff_against_baseline` and `off`, respectively, which makes it so that Starlark transitions can return to previous configurations, thus improving cache hit rates. Also changes the fixed platform suffix in the exec configuration from an empty string to `"exec"` for compatibility with logic that looks for the substring `-exec-` in paths to determine whether the current configuration is the exec configuration. As a result of this commit, output directory paths can change in the following ways: * `-ST-<hash>` suffixes can change or disappear and, in rare cases, appear where they previously didn't * for exec configuration directories, `k8-opt-exec-2B5CBBC6` becomes `k8-opt-exec-ST-011b9bdc32ed` This may result in tool paths that are seven characters longer, which can cause builds on Windows to fail that were already very close to the `MAX_PATH` limit. A follow-up commit will reduce the length of the hash by three characters, bringing that increase down to four. Work towards bazelbuild#14023 Closes bazelbuild#16910. PiperOrigin-RevId: 523999034 Change-Id: Id5548a00b62ebfe7889cd40177995210ecc224c1
Flips
--experimental_output_directory_naming_scheme
and--experimental_exec_configuration_distinguisher
todiff_against_baseline
andoff
, respectively, which makes it so that Starlark transitions can return to previous configurations, thus improving cache hit rates.Also changes the fixed platform suffix in the exec configuration from an empty string to
"exec"
for compatibility with logic that looks for the substring-exec-
in paths to determine whether the current configuration is the exec configuration.As a result of this commit, output directory paths can change in the following ways:
-ST-<hash>
suffixes can change or disappear and, in rare cases, appear where they previously didn'tk8-opt-exec-2B5CBBC6
becomesk8-opt-exec-ST-011b9bdc32ed
This may result in tool paths that are seven characters longer, which can cause builds on Windows to fail that were already very close to the
MAX_PATH
limit. A follow-up commit will reduce the length of the hash by three characters, bringing that increase down to four.Work towards #14023