Update 2.21 with latest changes#7116
Open
samanoelton wants to merge 10 commits into
Open
Conversation
The `Component` interface provides no typesafety to description
component classes. Its only purpose is to define the properties of the
Component decorator. Currently it only has optional properties, so it
matches the type `{}` which is as safe as `any`.
## Motivation for features / changes
Fix linter errors in test files to keep the codebase compliant with
current TypeScript and tslint rules in internal build.
## Technical description of changes
Cast `spyOn(store, 'dispatch') to jasmine.Spy` across 18 test files to
satisfy `NgRx` dispatch overload signatures. Updated `throwError to
factory form throwError(() => new Error(...))` per RxJS 7 requirements.
Added `tslint:disable-next-line:enforce-name-casing` suppressions for
snake_case keys that mirror backend API contracts.
Automated: Migrate {target_path} from gsutil to gcloud storage
This CL is part of the on going effort to migrate from the legacy
`gsutil` tool to the new and improved `gcloud storage` command-line
interface.
`gcloud storage` is the recommended and modern tool for interacting with
Google Cloud Storage, offering better performance, unified
authentication, and a more consistent command structure with other
`gcloud` components. 🚀
### Automation Details
This change was **generated automatically** by an agent that targets
users of `gsutil`.
The transformations applied are based on the [gsutil to gcloud storage
migration guide](http://go/gsutil-gcloud-storage-migration-guide).
### ⚠️ Action Required: Please Review and Test Carefully
While we have based the automation on the migration guide, every use
case is unique.
**It is crucial that you thoroughly test these changes in environments
appropriate to your use-case before merging.**
Be aware of potential differences between `gsutil` and `gcloud storage`
that could impact your workflows.
For instance, the structure of command output may have changed,
requiring updates to any scripts that parse it. Similarly, command
behavior can differ subtly; the `gcloud storage rsync` command has a
different file deletion logic than `gsutil rsync`, which could lead to
unintended file deletions.
Our migration guides can help guide you through a list of mappings and
some notable differences between the two tools.
Standard presubmit tests are run as part of this CL's workflow. **If you
need to target an additional test workflow or require assistance with
testing, please let us know.**
Please verify that all your Cloud Storage operations continue to work as
expected to avoid any potential disruptions in production.
### Support and Collaboration
The `GCS CLI` team is here to help! If you encounter any issues, have a
complex use case that this automated change doesn't cover, or face any
other blockers, please don't hesitate to reach out.
We are happy to work with you to test and adjust these changes as
needed.
**Contact:** `gcs-cli-hyd@google.com`
We appreciate your partnership in this important migration effort!
#gsutil-migration
Co-authored-by: gurusai-voleti <gvoleti@google.com>
## Motivation for features / changes This PR is the second step in a planned major Angular upgrade cycle, where each major version will be delivered in a separate PR, incrementally progressing until the project reaches Angular 21. This specific PR upgrades TensorBoard from Angular 16 to Angular 17 ## Technical description of changes - Upgrade Angular, NgRx, and Material from v16 to v17 - Upgrade TypeScript to 5.2.2 and zone.js to 0.14 - Use Node.js 18 in Bazel and CI (required by Angular 17) - Update build-tooling patch to match Angular 17 version - Fix Bazel TypeScript compiler crash caused by TypeScript 5.x - Fix 3 snackbar tests that broke due to Material 17 behavior change - Remove deprecated Material legacy theme APIs ## Screenshots of UI changes (or N/A) ## Detailed steps to verify changes work correctly (as executed by you) - All 2022 webapp tests pass - yarn lint passes with Node 18 - App builds and runs locally ## Alternate designs / implementations considered (or N/A)
## Motivation for features / changes Unblock internal LSC intended to remove workarounds for Sass and bad practices. Internal issue: b/508363660. This PR removes the wrappers for Sass build rules. Sass rules must directly declare their dependencies. Per Sass build rules guidelines, wrapper macros are discouraged, and tf_external_sass_libray was relying on a loophole (passing a sass_library to another sass_library's srcs) that is being closed. ## Technical description of changes - Replace `tf_sass_binary`,`tf_sass_library`, and `tf_external_sass_libray` wrappers with direct calls to `sass_binary`, `sass_library`, and `npm_sass_library` from `@io_bazel_rules_sass`. - Updated hash version rules_sass from 1.55.0 to 1.69.5 - Replaces the angular_material_sass_deps target with a direct npm_sass_library call. This produces a SassInfo provider consumed via deps, complying with the rule that sass libraries must declare deps directly rather than passing one library to another's srcs. - Added `include_paths = ["external/npm/node_modules"]` to each sass_binary so dart-sass can resolve `@use '@angular/material'`. The old wrapper set this automatically, now it has to be set per target. ## Detailed steps to verify changes work correctly (as executed by you) - BUILD - Standalone running - No console errors
## Summary This PR updates TensorBoard’s local Bazel/protobuf build stack to stay compatible with the TensorFlow 2.21 ecosystem changes that this branch needs: - Bazel 6.5.0 -> 7.7.0 - protobuf build/runtime alignment to 6.31.1 - related Bazel repo-loading, packaging, and test fixes needed for local source builds and CI The goal of this PR is to keep the smallest working set of changes needed to make the branch build, test, and package correctly with the upgraded toolchain. ## What changed ### Bazel / workspace updates - update `.bazelversion` and Bazel version guards to 7.7.0 - update workspace dependencies and repository wiring needed for Bazel 7 - keep existing repo setup model (`WORKSPACE`) rather than switching this PR to bzlmod ### Protobuf 6.31.1 alignment - update the Bazel-side protobuf dependency to 6.31.1 - add the small compatibility shims/patches needed for protobuf’s Bazel build in this repo - regenerate/update checked-in generated artifacts where required ### rules_closure / Soy compatibility - keep TensorBoard’s existing Closure/Soy toolchain working with protobuf 6 - vendor `third_party/safe_html_types` as a build-time Java dependency override for the existing Soy toolchain - explicitly prevent `rules_closure_dependencies(...)` from re-introducing conflicting older transitive copies ### Packaging and test fixes - keep `tensorboard.compat` package exports working correctly in Bazel runfiles and wheel/runtime smoke tests - keep `test_pip_package` and local Bazel test flows working under the upgraded toolchain - reduce PR-specific drift where possible by reverting summary modules back toward upstream import structure ## Vendored code This PR vendors `third_party/safe_html_types`, which is the main true vendored code in this branch. Why it is needed: - TensorBoard still uses the Closure/Soy Java toolchain during Bazel builds - the older transitive safe-html-types classes pulled by that toolchain were not working for this protobuf 6.31.1 upgrade path - this vendored copy is used as a build-time dependency override so the branch can stay on the upgraded Bazel/protobuf stack Why this is safe: - it is build-time Java tooling support, not TensorBoard Python runtime logic - it is not intended to change TensorBoard user-facing behavior - it is scoped to keeping the existing Soy/Closure path working with protobuf 6 We investigated avoiding vendoring here, but the straightforward `http_archive` alternatives we tried did not work for this branch’s current dependency combination. ## Review-driven cleanup in this PR In response to review, this PR now also: - adds clearer comments for patches and Bazel helper/shim files - documents the vendored `safe_html_types` dependency more explicitly - keeps optional cleanup/refactor work out of scope where possible - simplifies some summary-module changes back toward upstream shape ## Validation Validated through the local/container workflow used for this branch, including: - Bazel repo loading / fetch - focused and full Bazel test runs - pip package build - `test_pip_package` smoke validation - TensorBoard import/runtime verification against TensorFlow 2.21 ## Follow-up work The following are better handled in follow-up PRs rather than expanding this one further: - CI/setup-python cleanup and container-specific Python setup simplification - any future move to bzlmod - further dependency-management cleanup in `third_party/repo.bzl` - splitting this large change into smaller independently reviewable PRs once the full working baseline is settled
## Summary This PR simplifies the Python setup used by the main Bazel `build` job in CI. Previously, the self-hosted/container-based build job relied on `actions/setup-python`, and the workflow had to manually copy Python headers into the hosted-toolcache layout so Bazel's `@system_python` repository could find `Python.h` correctly. This PR removes that workaround by using container-managed Python 3.10 directly inside the build job. The goal is to keep the same Bazel build/test/package behavior while making the CI setup simpler and easier to maintain. ## What changed - removed `actions/setup-python` from the main `build` job - installed Python 3.10, `python3.10-dev`, and `python3.10-venv` directly in the container - created a local virtualenv for the job and used that interpreter for pip/Bazel-related steps - removed the manual Python header-copy workaround - removed the temporary debug steps that were only needed to diagnose the hosted-toolcache/header mismatch - kept the rest of the build/test/package flow unchanged ## Validation This change has been validated against the same CI behaviors as before: - `bazel fetch //tensorboard/...` - `bazel build //tensorboard/...` - `bazel test //tensorboard/...` - `bazel test //tensorboard/... --test_tag_filters="support_notf"` - `bazel build //tensorboard/pip_package:test_pip_package` - `./bazel-bin/tensorboard/pip_package/test_pip_package --tf-version tf-nightly` - `./bazel-bin/tensorboard/pip_package/test_pip_package --tf-version notf`
## Summary This PR does a small round of Bazel 7 cleanup and dependency-wiring simplification on top of the already-working Bazel 7 / protobuf 6 baseline. The goal is not to change dependency versions or CI behavior, but to reduce migration-specific scaffolding where it is no longer needed, keep the remaining shims clearly documented, and preserve a clean, working build/test state. ## What changed ### Repository helper cleanup - simplified `third_party/repo.bzl` - removed unused `tb_http_archive` support for `build_file` / `link_files` - kept `tb_http_archive` focused on the behaviors still used in this repo: - mirrored URLs - optional patch application ### WORKSPACE cleanup - switched mirror-only repositories back to plain `http_archive` where the TensorBoard-specific helper was no longer adding value - kept `tb_http_archive(...)` only for repositories that still need: - patch application - repo mapping - clarified comments around the remaining Bazel/protobuf compatibility repos ### Compatibility shim review - verified that `third_party/compatibility_proxy` is still required by the current `rules_java` / protobuf loading path - kept it in place rather than removing a live dependency - verified that `third_party/protobuf_pip_deps` and `third_party/protobuf_pip_deps_setuptools` are still required by protobuf 6.31.1’s Bazel macros and Python packaging flow - improved documentation explaining why those repos still exist ## Why this PR is useful This PR keeps the Bazel 7 migration easier to maintain by: - removing dead helper code - narrowing custom repository logic to the cases that still need it - documenting the remaining compatibility shims with concrete rationale - avoiding behavior changes to the working build graph ## Validation Validated with: - `bazel fetch //tensorboard/...` - `bazel build //tensorboard/... --nobuild` - `bazel build //tensorboard/...` - `bazel test //tensorboard/plugins/debugger_v2:debugger_v2_plugin_test` - full local Bazel test runs after the cleanup changes
## Summary Fixes an arbitrary file read issue in the TensorBoard Projector plugin by restricting asset paths to the directory that contains `projector_config.pbtxt`. Previously, user-controlled fields such as `metadata_path`, `tensor_path`, `bookmarks_path`, and `sprite.image_path` could resolve to absolute paths or traversal paths outside the intended logdir/config directory. That allowed a malicious config to make TensorBoard read and return arbitrary local files from the host. ## What Changed - Hardened projector asset path resolution to: - expand and normalize candidate paths - resolve them against the directory containing `projector_config.pbtxt` - reject any path that escapes that directory boundary - Returned a clean `400` response when a requested asset path is invalid - Applied this validation consistently across: - metadata loading - tensor loading - bookmarks loading - sprite image loading - Updated config augmentation logic to safely skip invalid external tensor paths instead of trying to read them ## Security Impact This closes a path traversal / arbitrary local file read vector in the Projector plugin for deployments where an attacker can write or influence `projector_config.pbtxt` contents under a scanned logdir. ## Tests Added projector integration coverage for: - `metadata_path` using traversal outside the logdir - `tensor_path` using an absolute path outside the logdir - `bookmarks_path` using an absolute path outside the logdir - `sprite.image_path` using traversal outside the logdir ## Validation Verified: - `python -m py_compile tensorboard/plugins/projector/projector_plugin.py tensorboard/plugins/projector/projector_plugin_test.py` - `bazel test //tensorboard/plugins/projector:projector_plugin_test` - Full build and test suite ## Risk / Compatibility Low risk for valid configurations. This change may reject projector configs that previously referenced assets outside the config directory, but that behavior is now considered unsafe and is intentionally blocked.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Update 2.21 branch for release process