feat(dev-infra): create shared platform for remote execution #41767
Closed
devversion wants to merge 5 commits into
Closed
feat(dev-infra): create shared platform for remote execution #41767devversion wants to merge 5 commits into
devversion wants to merge 5 commits into
Conversation
12f7219 to
bc48671
Compare
Introduces a shared Bazel platform for remote execution builds using Google cloud. Previously we used `bazel_toolchains` for providing the platform w/ additional CPP and Java toolchains `bazel_toolchains` no longer provides default toolchains with the latest version, but provides a tool (linux and windows only) for generating toolchain/platforms, which then need to be checked into the repository. This is quite inconvenient and cumbersome (especially with no macOS support), so we just provide our own platform and CPP toolchain within `//dev-infra`. This is more simple than all the effort we'd need to make the toolchain generation tool work (while it would also increase the amount of checked-in sources significantly; with more unused toolchains for CPP or Java)
bc48671 to
35c284d
Compare
A test for the dev-infra publish tool currently relies on an external http request by accident. This will break if we disallow internet access within RBE containers.
Uses the new shared RBE platform from the dev-infra package.
35c284d to
2f3c3bb
Compare
Member
Author
|
Note that this also fixes RBE on macOS and allows potential use w/ Windows (I got RBE working in the past) |
josephperrott
approved these changes
Apr 23, 2021
josephperrott
left a comment
Member
There was a problem hiding this comment.
LGTM
Just the one comment, but it's not a huge deal.
jessicajaniuk
pushed a commit
that referenced
this pull request
Apr 23, 2021
Introduces a shared Bazel platform for remote execution builds using Google cloud. Previously we used `bazel_toolchains` for providing the platform w/ additional CPP and Java toolchains `bazel_toolchains` no longer provides default toolchains with the latest version, but provides a tool (linux and windows only) for generating toolchain/platforms, which then need to be checked into the repository. This is quite inconvenient and cumbersome (especially with no macOS support), so we just provide our own platform and CPP toolchain within `//dev-infra`. This is more simple than all the effort we'd need to make the toolchain generation tool work (while it would also increase the amount of checked-in sources significantly; with more unused toolchains for CPP or Java) PR Close #41767
devversion
added a commit
to devversion/material2
that referenced
this pull request
Apr 23, 2021
Uses the new shared RBE platform from the dev-infra package. We introduced a shared Bazel platform for remote execution builds using Google cloud. Previously we used `bazel_toolchains` for providing the platform w/ additional CPP and Java toolchains `bazel_toolchains` no longer provides default toolchains with the latest version, but provides a tool (linux and windows only) for generating toolchain/platforms, which then need to be checked into the repository. This is quite inconvenient and cumbersome (especially with no macOS support), so we just provided our own platform and CPP toolchain within `//dev-infra`. This is more simple than all the effort we'd need to make the toolchain generation tool work (while it would also increase the amount of checked-in sources significantly; with more unused toolchains for CPP or Java) See: angular/angular#41767.
devversion
added a commit
to devversion/material2
that referenced
this pull request
Apr 27, 2021
Uses the new shared RBE platform from the dev-infra package. We introduced a shared Bazel platform for remote execution builds using Google cloud. Previously we used `bazel_toolchains` for providing the platform w/ additional CPP and Java toolchains `bazel_toolchains` no longer provides default toolchains with the latest version, but provides a tool (linux and windows only) for generating toolchain/platforms, which then need to be checked into the repository. This is quite inconvenient and cumbersome (especially with no macOS support), so we just provided our own platform and CPP toolchain within `//dev-infra`. This is more simple than all the effort we'd need to make the toolchain generation tool work (while it would also increase the amount of checked-in sources significantly; with more unused toolchains for CPP or Java) See: angular/angular#41767.
andrewseguin
pushed a commit
to angular/components
that referenced
this pull request
Apr 28, 2021
#22555) Uses the new shared RBE platform from the dev-infra package. We introduced a shared Bazel platform for remote execution builds using Google cloud. Previously we used `bazel_toolchains` for providing the platform w/ additional CPP and Java toolchains `bazel_toolchains` no longer provides default toolchains with the latest version, but provides a tool (linux and windows only) for generating toolchain/platforms, which then need to be checked into the repository. This is quite inconvenient and cumbersome (especially with no macOS support), so we just provided our own platform and CPP toolchain within `//dev-infra`. This is more simple than all the effort we'd need to make the toolchain generation tool work (while it would also increase the amount of checked-in sources significantly; with more unused toolchains for CPP or Java) See: angular/angular#41767.
clydin
pushed a commit
to angular/angular-cli
that referenced
this pull request
May 5, 2021
Uses the new shared RBE platform from the dev-infra package. We introduced a shared Bazel platform for remote execution builds using Google cloud. Previously we used `bazel_toolchains` for providing the platform w/ additional CPP and Java toolchains `bazel_toolchains` no longer provides default toolchains with the latest version, but provides a tool (linux and windows only) for generating toolchain/platforms, which then need to be checked into the repository. This is quite inconvenient and cumbersome (especially with no macOS support), so we just provided our own platform and CPP toolchain within `@angular/dev-infra-private`. This is more simple than all the effort we'd need to make the toolchain generation tool work (while it would also increase the amount of checked-in sources significantly; with more unused toolchains for CPP or Java) See: angular/angular#41767.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
This file contains hidden or 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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Introduces a shared Bazel platform for remote execution builds
using Google cloud. Previously we used
bazel_toolchainsforproviding the platform w/ additional CPP and Java toolchains
bazel_toolchainsno longer provides default toolchains with thelatest version, but provides a tool (linux and windows only) for
generating toolchain/platforms, which then need to be checked
into the repository. This is quite inconvenient and cumbersome
(especially with no macOS support), so we just provide our own
platform and CPP toolchain within
//dev-infra. This is moresimple than all the effort we'd need to make the toolchain
generation tool work (while it would also increase the amount
of checked-in sources significantly; with more unused toolchains
for CPP or Java)