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

Wire up credential helper to command-line flag(s) #4

Draft
wants to merge 25 commits into
base: yannic-cr-mv-factory
Choose a base branch
from

Conversation

Yannic
Copy link
Member

@Yannic Yannic commented Jul 21, 2022

RELNOTES: Add support for fetching RPC credentials from a
credential helper. This release note clearly needs improvement!

Progress on bazelbuild#15856

justinhorvitz and others added 9 commits July 21, 2022 08:00
…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
tjgq and others added 16 commits July 22, 2022 05:08
… 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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.