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.

Sign up for GitHub

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

Jump to bottom

Bazel at HEAD breaks skylib: no matching toolchains found #8227

Closed
c-parsons opened this issue May 2, 2019 · 5 comments
Closed

Bazel at HEAD breaks skylib: no matching toolchains found #8227

c-parsons opened this issue May 2, 2019 · 5 comments
Assignees
@c-parsons
Labels
P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug

Comments

@c-parsons
Copy link
Contributor

It looks like 771cb7a introduces a breakage of bazel-skylib (example) that is quite hard to reproduce. The error itself is:

ERROR: While resolving toolchains for target //tests:change_setting_test: no matching toolchains found for types @bazel_skylib//toolchains/unittest:toolchain_type
ERROR: Analysis of target '//tests:change_setting_test' failed; build aborted: no matching toolchains found for types @bazel_skylib//toolchains/unittest:toolchain_type

However, it seems that one can only see this error in a roundabout fashion (which so happens is the manner in which bazel-skylib is rerun). The incantation (from the bazel-skylib root):

bazelAtHead build //... --incompatible_remap_main_repo

(fetches occur and everything passes)

bazelAtHead test //...

(build fails, as one would expect, because bazel-skylib requires the --incompatible_remap_main_repo flag to build.

bazelAtHead test //... --incompatible_remap_main_repo

Everything fails, with the above error.
Then subsequent invocations of

bazelAtHead build //... --incompatible_remap_main_repo

also result in the given error.
@c-parsons
Copy link
Contributor Author

May be fixed by cc943c5 (verifying)

@c-parsons c-parsons added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. P1 I'll work on this now. (Assignee required) type: bug labels May 2, 2019
@laszlocsomor
Copy link
Contributor

/cc @laszlocsomor

@aehlig aehlig mentioned this issue May 3, 2019
Closed
@c-parsons
Copy link
Contributor Author

Looks like cc943c5 did not actually fix this :(
I'll issue rollbacks for both...

bazel-io pushed a commit that referenced this issue May 3, 2019
@c-parsons @copybara-github
Automated rollback of commit cc943c5.
333cc8c 
*** Reason for rollback ***

Needed to rollback larger charge which breaks bazel-skylib

(See #8227 for breakage details)

*** Original change description ***

Check if a toolchain was loaded from a bzl file in the MAIN workspace then put it in the map under "@" as opposed to the main repo's name.

RELNOTES: None
PiperOrigin-RevId: 246528284
bazel-io pushed a commit that referenced this issue May 3, 2019
@c-parsons @copybara-github
Automated rollback of commit 771cb7a.
dac2135 
*** Reason for rollback ***

Breaks bazel-skylib

See #8227 for details.

*** Original change description ***

Make target pattern parsing repository-renaming aware.

Platform and toolchain resolution rely on the target pattern parsing code to turn target pattern strings into Labels. Since most of the target pattern parsing codepaths turn target patterns that originated from the command line, they don't need to pass along the repository renaming map. But instances that affect platform and toolchain target patterns, we need to pass the map.

This allows us to turn on the --incompatible_remap_main_repo flag on by default in Bazel.

Closes #7902.
Fixes #7755, #7773, #7654.

RELNOTES: None
PiperOrigin-RevId: 246546091
@c-parsons
Copy link
Contributor Author

Confirmed the rollbacks have fixed bazel-skylib.
Lowering priority -- there is still some concerning behavior here, but there won't be any bugs exhibited at HEAD.

@c-parsons c-parsons removed their assignment May 3, 2019
@dkelmer dkelmer added P2 We'll consider working on this in future. (Assignee optional) and removed P1 I'll work on this now. (Assignee required) labels May 10, 2019
@c-parsons c-parsons assigned c-parsons and unassigned dkelmer Jun 6, 2019
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
@c-parsons
Copy link
Contributor Author

For those running into this issue today,

If the issue is easily reproducible, the most likely explanation is that you've forgotten to follow the instructions at https://github.com/bazelbuild/bazel-skylib#workspace-file (specifically, adding that full stanza to your WORKSPACE file).

I'm not actively looking into this anymore, and I haven't gotten additional reports that this is happening flakily. I'm going to close this, but feel free to reopen if it arises again.

@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
luca-digrazia pushed a commit to luca-digrazia/DatasetCommitsDiffSearch that referenced this issue Sep 4, 2022
Automated rollback of commit cc943c55324499379e0f63902899c85a9b8089b8.
d74e3b5 
    *** Reason for rollback ***

    Needed to rollback larger charge which breaks bazel-skylib

    (See bazelbuild/bazel#8227 for breakage details)

    *** Original change description ***

    Check if a toolchain was loaded from a bzl file in the MAIN workspace then put it in the map under "@" as opposed to the main repo's name.

    RELNOTES: None
    PiperOrigin-RevId: 246528284
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@c-parsons c-parsons

Labels
P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@philwo @dkelmer @laszlocsomor @c-parsons