forked from bazelbuild/bazel
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Wire up credential helper to command-line flag(s) #4
Draft
Yannic
wants to merge
25
commits into
yannic-cr-mv-factory
Choose a base branch
from
yannic-ch-flags
base: yannic-cr-mv-factory
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…crash instead of a bug report. I see no recent history of this bug report, and it could have been explained by b/236308456. PiperOrigin-RevId: 462383973 Change-Id: I202cbf26380f0e29bcb6b9d4b0c6739f95b02da8
Baseline: ea8b99c Cherry picks: + 107a54e: Fix flag file regexp broken by bazelbuild@cb2cd9fd2b65311da92777 7c35939701add5b879. + 1e7127d: Reinstate legacy worker flag file behaviour when not using --experimental_worker_strict_flagfiles. Incompatible changes: - Flag --experimental_local_memory_estimate removed. This release contains contributions from many people at Google, as well as Fabian Meumertzheim, Tomas Volf, Yannic Bonenberger.
--nobuild. When there's no execution phase, running blaze with skymeld doesn't make sense since there's no overlapping. In that case, we ignore the flag. Why not throw an error? In the future if someone wants to use aquery/cquery (which implicitly has --nobuild) while having --experimental_merged_skyframe_analysis_execution in their bazelrc, it would add too much friction if an error was thrown. PiperOrigin-RevId: 462392726 Change-Id: I7c8a379ccb7318cf8c6dee38a67e2a8ee14e9683
RELNOTES: None PiperOrigin-RevId: 462468516 Change-Id: I41d599e3ff9a3df3be9bc750f83b8a6b9ec9c7bd
This lets us use --experimental_bzl_visibility_allowlist to enable the .bzl load-visibility unconditionally. This eases migration for graveyarding the flag. Also did a drive-by docs tweak. Work towards bazelbuild#11261. PiperOrigin-RevId: 462480270 Change-Id: Ia877bb5947db7655d91e4838f4b8a5162df9580b
Allow StarlarkValue#str to access StarlarkSemantics This allows us to alter the behavior of `str(some_starlark_value)` depending on flags. See child CL for an example. This involves adding the StarlarkSemantics argument to a rather long list of call sites and implementors, but it helps in the end to clarify that stringification is really dependent on starlark semantics. END_PUBLIC Work towards bazelbuild#15916 PiperOrigin-RevId: 462564920 Change-Id: I1733424a5657e54cb19f117b8b5dc7af76ca0842
`usedHeapSizePostBuild` was always 0 ever since bazelbuild@d9a523e. PiperOrigin-RevId: 462575294 Change-Id: I065d79501a6866541a030e1cc757ecd6040f4bc3
Follow-up on bazelbuild#15930 due to bazelbuild#15906 Progress on bazelbuild#15856 Closes bazelbuild#15941. PiperOrigin-RevId: 462580799 Change-Id: Ibac79ed68a0c87a4f34eb9d0729abb1552b44519
RELNOTES: Add support for fetching RPC credentials from a credential helper. This release note clearly needs improvement! Progress on bazelbuild#15856
… directories, and that the input/output should match (i.e., both files or both directories). Unfortunately, we currently allow file-to-directory symlinks, so we must temporarily keep allowing them until existing callers are fixed. We can, however, disallow directory-to-file symlinks straight away, as passing a directory output to `ctx.actions.symlink` currently doesn't work (the action would attempt to create a symlink over an existing directory and fail). I have a separate pending CL to make output directories work, which is why it's important to submit this check first. PiperOrigin-RevId: 462596724 Change-Id: Ia7ba0ebfea50f9a0265a83345e75a633c653e5a7
With the new output mode `--output=files`, cquery lists all files advertised by the matched targets in the currently requested output groups. This new mode has the following advantages over `--output=starlark` combined with an appropriate handcrafted `--starlark:expr`: * provides a canonical answer to the very common "Where are my build outputs?" question * is more friendly to new users as it doesn't require knowing about providers and non-BUILD dialect Starlark * takes the value of `--output_groups` into account * stays as close to the logic for build summaries printed by `bazel build` as possible Fixes bazelbuild#8739 RELNOTES: `cquery`'s new output mode [`--output=files`](https://bazel.build/docs/cquery#files-output) lists the output files of the targets matching the query. It takes the current value of `--output_groups` into account. Closes bazelbuild#15552. PiperOrigin-RevId: 462630629 Change-Id: Ic648f22aa160ee57b476180561b444f08799ebb6
RELNOTES: Change singlejar metadata to report Created-By Bazel PiperOrigin-RevId: 462631128 Change-Id: If2ac809dd0178e71ccf29f5a3abc175279ba85da
Fixes : bazelbuild#14518 PiperOrigin-RevId: 462641379 Change-Id: I152bb90be4951e2a68973967f0370aaed059dd7b
Since unknown commit `Sets#newConcurrentHashSet` uses `ConcurrentHashMap#newKeySet`, which implements `add` more efficiently by simulating `putIfAbsent`, which does not lock if the key is already present. Also remove the unused type parameter. PiperOrigin-RevId: 462645284 Change-Id: I7113f863f9395ab6474159fb8070b3b2c80131c6
…tionCache` and document potential concerns of the `xor` strategy. Fixes bazelbuild#15660 PiperOrigin-RevId: 462652492 Change-Id: I023997e7b6d78be7028a72d631a11080f178c13d
The logic assumed all edges had attributes. Visibility edges don't. This only applies to targets that set visibility to a package group (so there's technically an edge from the target to the package group's label). Generic visibility like public, private doesn't trigger this. PiperOrigin-RevId: 462672353 Change-Id: I57173129dcf6f4ac6de617c5d61f5a7b3df05e63
This patch prevents aspect functions from being evaluated when their associated targets are incompatible. Otherwise aspects can generate errors that should never be printed at all. For example, an aspect evaluating an incompatible target may generate errors about missing providers. This is not the desired behaviour. The implementation in this patch short-circuits the `AspectValue` creation if the associated target is incompatible. I had tried to add an `IncompatiblePlatformProvider` to the corresponding `ConfiguredAspect` instance, but then Bazel complained about having duplicate `IncompatiblePlatformProvider` instances. Fixes bazelbuild#15271 Closes bazelbuild#15426. PiperOrigin-RevId: 462678126 Change-Id: I6cd6d4d9936bb1dde6a1282399ed4adc389ceed1
…repare_analysis a no-op As discussed in other bugs, it was discovered that PrepareAnanlysisPhaseFunction is improperly computing the post-transition configurations of top-level targets. (As a quick summary, the nested-while loop is effectively scrambling the configurations amongst different top-level targets. I think it is missing a continue.) Since, experimental_skyframe_prepare_analysis is now off by default, this code path does not see much, if any, use and thus don't see need to maintain it (especially as it tries to mirror pre-existing logic in SkyframeExecutor). Also, since this specific experiment was tried, transition application caching was added, which essentially steals a lot of the potential for performance benefits here. While moving more code to Skyframe is likely good overall, this specific experiment has been stalled out for years. If later desired, would want to restart this effort with fresh code and a more aggressive timeline for completing the experiment to avoid having the mirrored code paths fall out of sync again. PiperOrigin-RevId: 462687226 Change-Id: Ifb4629c8d46cc378998693987c5190ba6ab79433
Added 'rdeps' as a quick utility to get rdeps out of Skyframe since dumping and reading the text file can be a bit laborious. Replace --skyfunction_filter with --skykey_filter since --skyfunction_filter can be a bit too coarse-grained. Rename 'detailed' as 'deps' for symmetry with new 'rdeps' option. PiperOrigin-RevId: 462707385 Change-Id: I52a6019d35c7ad285778fba8edc4dc1272c76ea1
RELNOTES: None PiperOrigin-RevId: 462740033 Change-Id: I61ad63ef63b84f00defc822df83630bad7541089
Two main goals of this CL: * Properly include 'metadata about Starlark build settings' in the transition application cache. * Better isolate where and why the transition infrastructure reads BUILD file information. This unifies previously duplicated logic in SkyframeExecutor. First, the transition application cache, on a miss, would also read defaults, type, aliasing information, etc. from BUILD files but failed to include any of this info in the cache key. This lead to failure to re-evaluate a transition when that build setting information in BUILD files changes. This CL fixes that by introducing a new type StarlarkBuildSettingsDetailsValue, which contains all that information for a given set of Starlark build settings. That value is now included in the cache key. Second, rather than having ConfiguredTargetFunction (via machinery in StarlarkTransition) itself do the Skyframe calls and subsequent computations necessary to compute StarlarkBuildSettingsDetailsValue, a new SkyFunction StarlarkBuildSettingsDetailsFunction was created to do so. This provides a few benefits: 1. ConfiguredTargetFunction now is only registering an edge onto a single StarlarkBuildSettingsDetailsFunction, rather than all the PackageValue needed to resolve the StarlarkBuildSettings. StarlarkBuildSettingsDetailsValue more narrowly describes how sensitive the transition is to change. This means irrelevant changes to a package involved in build setting resolution will not cause as much invalidation. This information is now cached so StarlarkTransition (called via ConfiguredTargetFunction) can more quickly compute the cache key. (Beforehand, it was always unconditionally following any build setting alias chains). 2. SkyframeExecutor can just evaluate StarlarkBuildSettingsDetailsValue rather than having a slightly different implementation getBuildSettingsPackages. (The new getStarlarkBuildSettingsDetailsValue functions that must be synced are much simpler and easier to keep in sync.) As part of this unification, the error messages are now consistent regardless of whether the problematic build settings are asked for when transitioning the top-level target or an underlying target. 3. The split between reading Packages to compute StarlarkBuildSettingsDetailsValue and then later consuming it in StarlarkTransition should be easier to read and maintain. PS: As part of the refactor, significant issues were found in PrepareAnalysisPhaseFunction. Warnings have been added as comments and upcoming work will be deleting that file entirely. This fixes caching issue described at bazelbuild#15732 PiperOrigin-RevId: 462741847 Change-Id: I517a9a841735e6cff26faea5373f50a164334f86
…ain repo Right now, we only fail on an invisible RepositoryName in RepositoryDelegatorFunction#compute. The problem is that when someone uses a label '@//foo:bar' but doesn't have visibility into the main repo, this check is not performed. The good news is that such a usage still fails due to a "cross repository check" -- since `RepositoryName.MAIN.toNonVisible(X)` is not equal to `RepositoryName.MAIN`. The bad news is that the error message is *very* confusing, with something like "Invalid package reference @//foo crosses into repository @: did you mean to use @//foo instead?". This CL fixes the error message to be similar to when a non-main repo is used in violation of strict-deps: something like "Repository '@' is not visible from repository '@x'". PiperOrigin-RevId: 463026687 Change-Id: I25b3d2ec8b3150feae226cd5ef660819188be1a0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
RELNOTES: Add support for fetching RPC credentials from a
credential helper. This release note clearly needs improvement!
Progress on bazelbuild#15856