Notes to reviewer:
- modules/canvaskit/npm_build/types/canvaskit-wasm-tests.ts
is not actual test code that is executed. It is parsed with
our types (index.d.ts) only, as a way to make sure the
declared types match up with how one would write code.
- MakeDisplacementMap looked a bit strange when I tried to
use it. It might be easiest to debug if we land as is,
so we can use jsfiddle to test dynamic parameters.
- modules/canvaskit/package-lock.json was updated by running
npm audit fix.
- There are two copies of the test cases, one for the old
way, and one for Bazel. Getting Bazel on the CI is currently
blocked (http://review.skia.org/547576)
- I am adding all the image filters in by default for now,
we can measure code size and adjust them if needed later.
Change-Id: I2f4eae71de7ee5d53f0c74147d0662f156522d18
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/555596
Owners-Override: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
PredefinedColorSpace was not available before then.
To upgrade the package-lock.json, I deleted the node_modules
folder in npm_build and the existing package-lock.json,
then ran `npm install` (using npm 7.20.6, along with node
14.15.0).
There was still an issue with the order of types in
the type union for readPixels. Apparently, TS changed
this slightly in a version upgrade. To address this,
I added an "or" to that type assertion, along with
a comment.
I double-checked the necessity of reference types="@webgpu/types"
and this is needed to use things like GPUTexture and
GPUDevice.
Change-Id: I7044ae562c155ad4405dbc0e3d647601014fefdc
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/557738
Reviewed-by: Arman Uguray <armansito@google.com>
Change-Id: I07c0cb63286cb2c74853a49a44a9ee5ae7b994c9
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/557102
Commit-Queue: John Stiles <johnstiles@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The tools in genrules [1] correspond to the HOST's version, which
is a problem if we are doing cross-platform builds. In this case,
when I was using my M1 Mac to run on a Linux RBE platform, the
Mac's python binaries (e.g. python3_9_aarch64-apple-darwin/bin/python3)
were being uploaded to RBE and attempted to be used, which resulted
in OSError: [Errno 8] Exec format error because the won't run
on the Linux RBE machine.
Thanks to tjgq@, I learned about exec_tools [2], which will use
the version of the tools for the EXECUTION platform, which
is exactly what we want.
While debugging this, I added a minimal reproduction case in
//experimental/bazel_test and updated the py_tools version
in an effort to diagnose the issue further.
We will need to contribute similar fixes to @spirv_tools
[1] https://bazel.build/reference/be/general#genrule.tools
[2] https://bazel.build/reference/be/general#genrule.exec_tools
Bug: skia:12541
Change-Id: Ib14deb4e326d3103fd08c21e93afe342d751c17a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/554518
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
Several canvases in the npm_build/example.html demo now use WebGPU if it
is supported by the browser and the CanvasKit build in use.
The examples have been refactored to support both WebGPU and non-WebGPU
mode of usage. Two examples that currently rely on Surface.drawOnce
don't work correctly on WebGPU as the API call may draw to the wrong
swapchain texture ("paths" and "pathperson") and will benefit from a
`WebGPUCanvasContext.drawOnce` function.
Bug: skia:13427
Change-Id: I16dc06a9788cf78e86b2097f44c1f83ca0b2315a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/553637
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
* The native backend exposes a variant of _MakeGrContext that creates a
GrDirectContext backed by a Dawn wgpu::Device.
* The native backend currently exposes a single API function,
"_MakeGPUTextureSurface" which returns a SkSurface from Dawn backend
render target over a Dawn wgpu::Texture. This function can be used to
draw to any WebGPU texture, including offscreen textures or to a
canvas swapchain texture.
* The MakeGPUDeviceContext, MakeGPUCanvasContext, MakeGPUCanvasSurface
functions are implemented purely in JavaScript.
* The CanvasKit.webgpu property can be used to detect whether WebGPU
support has been compiled in.
Bug: skia:13427
Change-Id: I953f24ca58389d5989a108685abbc02e56d4e18b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/553636
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
The big change here is having the C++ toolchain use
Bazel platforms instead of the C++ specific flags/setup.
In Bazel, platforms are a general purpose way to define
things like os, cpu architecture, etc. We were not using
platforms previously, because the best documentation at
the time focused on the old ways.
However, the old ways were clumsy/difficult when trying
to manage cross-compilation, specifically when trying
to have a Mac host trigger a build on our Linux RBE
system targeting a Linux x64 system. Thus, rather than
keep investing in the legacy system, this CL migrates
us to using platforms where possible.
Suggested background reading to better understand this CL:
- https://bazel.build/concepts/platforms-intro
- https://bazel.build/docs/platforms
- https://bazel.build/docs/toolchains#registering-building-toolchains
The hermetic toolchain itself is not changing in this CL
(and likely does not need to), only how we tell Bazel
about it (i.e. registering it) and how Bazel decides
to use it (i.e. resolving toolchains).
Here is my understanding of how platforms and toolchains
interact (supported by some evidence from [1][2])
- Bazel needs to resolve platforms for the Host, Execution,
and Target.
- If not specified via flags, these are the machine from
which Bazel is invoked, aka "@local_config_platform//:host".
- With this CL, the Host could be a Mac laptop, the Execution
platform is our Linux RBE pool, and the Target is "a Linux
system with a x64 CPU"
- To specify the Host, that is, describe to Bazel the
capabilities of the system it is running on, one can
set --host_platform [3] with a label pointing to a platform()
containing the appropriate settings. Tip: have this
platform inherit from @local_config_platform//:host
so it can add to any of the constraint_settings and
constraint_values that Bazel deduces automatically.
- To specify the Target platform(s), that is, the system
on which a final output resides and can execute, one
can set the --platforms flag with a label referencing
a platform().
- Bazel will then choose an execution platform to fulfill
that request. Bazel will look through a list of available
platforms, which can be augmented* with the
--extra_execution_platforms. Platforms specified by this
flag will be considered higher than the default platforms!
- Having selected the appropriate platforms, Bazel now
needs to select a toolchain to actually run the actions
of the appropriate type.
- Bazel looks through the list of available toolchains
and finds one that "matches" the Execution and the Target
platform. This means, the toolchain's exec_compatible_with
is a strict subset of the Execution platform and
the toolchain's target_compatible_with is a strict subset
of the Target platform. To register toolchains* (i.e. add
them to the resolution list), we use --extra_toolchains.
Once Bazel finds a match, it stops looking.
Using --toolchain_resolution_debug=".*" makes Bazel log
how it is resolving these toolchains and what execution
platform it picked.
* We can also register execution platforms and toolchains in
WORKSPACE.bazel [4], but the flags come with higher priority
and that made resolution a bit tricky. Also, when we want
to conditionally add them (e.g. --config=linux_rbe), we
cannot remove them conditionally in the WORKSPACE.bazel file.
The above resolution flow directly necessitated the changes
in this CL.
Example usage of the new configs and platforms:
# Can be run on a x64 Linux host and uses the hermetic toolchain.
bazel build //:skia_public
# Can be run on Mac or Linux and uses the Linux RBE system along
# with the hermetic toolchain to compile a binary for Linux x64.
bazel build //:skia_public --config=linux_rbe --config=for_linux_x64
# Shorthand for above
bazel build //:skia_public --config=for_linux_x64_with_rbe
Notice we don't have to type out --config=clang_linux anymore!
That was due to me reading the Bazel docs more carefully and
realizing we can set options for *all* Bazel build commands.
Current Limitations:
- Targets which require a py_binary (e.g. Dawn's genrules)
will not work on RBE when cross compiling because the
python runtime we download is for the host machine, not
the executor. This means //example:hello_world_dawn does
not work on Mac when cross-compiling via linux_rbe.
- Mac M1 linking not quite working with SkOpts settings.
Probably need to set -target [5]
Suggested Review order:
- toolchain/BUILD.bazel Notice how we do away with
cc_toolchain_suite for toolchain. These have the same
role: giving Bazel the information about where a toolchain
can run. The platforms one is more expressive (IMO), allowing
us to say both where to run the toolchain and what it can
make. In order to more easily force the use of our hermetic
toolchain, but also allow the hermetic toolchain to be used
on RBE, we specify "use_hermetic_toolchain" only on the target,
because the RBE image does not have the hermetic toolchain
on it by default (but can certainly run it).
- bazel/platform/BUILD.bazel to see the custom constraint_setting
and corresponding constraint_value. The names for both of these
are completely arbitrary - they do not need to have any deeper
meaning or relation to any file or Docker image or system or
any other constraints. Think of the constraint_setting as
an Enum and the constraint_value being the one and only member.
We need to pass around a constant value, not a type, so we
need to provide the constraint_value (e.g. in toolchain/BUILD.bazel)
but not a constraint_setting. However we need a
constraint_setting declared so we can make a constraint_value
of that "type".
Notice the platform declared here - it allows us to force
Bazel to use the hermetic toolchain because of the extra
constraint_value.
- .bazelrc I set a few flags that will be on for all
bazel build commands. Importantly, this causes the C++
build logic to use platforms and not the old, bespoke way.
I also found a way to avoid using the local toolchain on
the host, which will hopefully lead to clearer errors
if platforms are mis-specified instead of odd compile
errors because the host toolchain is too old or something.
There are also a few RBE settings tweaked to be a bit
more modern, as well the new shorthands for specifying
target platforms (e.g. for_linux_x64).
- bazel/buildrc where we have to turn off the platforms
logic for emscripten https://github.com/emscripten-core/emsdk/issues/984
- bazel/rbe/BUILD.bazel for a fix in the platform description
that makes it work on Mac.
- Notice that _m1 has been removed from the mac-related toolchain
files because the same toolchain should work on both
architectures.
- All other changes in any order.
[1] https://bazel.build/docs/toolchains#debugging-toolchains
[2] https://bazel.build/docs/toolchains#toolchain-resolution
[3] https://bazel.build/reference/command-line-reference
[4] https://bazel.build/docs/toolchains#registering-building-toolchains
[5] 17dc3f16fc/gn/skia/BUILD.gn (L258-L271)
Change-Id: I515c114099d659639a808f74e47d489a68b7af62
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549737
Reviewed-by: Erik Rose <erikrose@google.com>
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
* Skia GN can now build the Dawn backend without depending on Dawn
native, provided that webgpu_cpp.h/webgpu_cpp.cpp is provided by
emscripten.
* Split gpu.js into webgl.js and webgpu.js. None of the CanvasKit API
functions are wired up to WebGPU yet so it will use the CPU renderer.
* Added new macros and GN args to distinguish between WebGPU and WebGL
builds in CanvasKit, instead of relying on Skia GN args.
* Renamed CANVASKIT_NO_ALIAS_FONT macro to CK_NO_ALIAS_FONT to match
style.
Bug: skia:12512
Change-Id: Ifc4191da046bd7af73492cfba6e3ca530590d722
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/548603
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Commit-Queue: Arman Uguray <armansito@google.com>
Bug: chromium:1335249
Change-Id: I441d48fd97e0fccfb25de2bd4a2d8006c2e80ce7
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/549038
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Organization v3.5, if we are keeping track :)
This splits the "srcs" filegroup into "srcs" and "private_hdrs",
and renames "hdrs" to "public_hdrs".
To assist with the split, I created the macro split_srcs_and_hdrs.
Rather than keep two separate lists of header and source files,
I figured it would be easiest, at least for the common case,
to keep one list of files and then have a for loop split them
apart. I've tried to be consistent with having the list
of files be named with a _FILES suffix - maybe we can use this
as a marker to generate .gni files in the future?
Suggested review order:
- //bazel/macros.bzl. Note this needs a corresponding
G3 change (http://cl/452279799) as well. The exports_files_legacy
change is the better approach to something I manually
handled yesterday when fixing the G3 roll.
- //BUILD.bazel to see the new target skia_internal and
the previous skia_core renamed to skia_public.
- //src/core/BUILD.bazel to see a typical usage of
split_srcs_and_hdrs.
- //include/... to see the change to public_hdrs and
private_hdrs
- //src/... to see many more usages of split_srcs_and_hdrs
- //tools/... to see changes to skia_internal where
appropriate.
- Everything else. Note that //modules/... might also need
to be built with skia_internal instead of skia_public,
but we can fix that up later, if necessary.
Change-Id: Ie1cc969455d97b029b2d77faa222c4a9bad70671
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/545716
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
This may look like a lot, but //modules/canvaskit/BUILD.bazel
is nearly identical to how it was with gazelle:
162dfca340/modules/canvaskit/BUILD.bazel
I removed the "wasm_gm_tests" targets from it, because they
had bitrotted slightly and fixing them is its own task.
CanvasKit depends on Skottie and Particles, which depend on
the SkParagraph, SkShaper, SkUnicode, and SkResources modules.
I've structured the BUILD.bazel files in the //modules directory
in a similar fashion as the "hierarchical filegroup"
introduced in https://skia-review.googlesource.com/c/skia/+/543977
Suggested Review Order
- //modules/skottie/...
- //modules/skparagraph/...
- all other modules.
- Note that modules/canvaskit/go/gold_test_env/BUILD.bazel is
generated from gazelle, because we like how gazelle handles
golang files and deps.
- All other files in any order.
Change-Id: I0aa9e6f81dba2c00f15cae7b19fe49a2027dcf1d
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/544676
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
gazelle ended up being more liability than asset for our C++ rules.
It required devs to manually run the command frequently (and was
easy to forget until the CQ failed). The fact that we still had to
edit the source files (e.g. the "srcs" cc_libraries) meant that
the mixture between generated and hand-written caused some
tension (see include/third_party/vulkan for a good example).
The combination of gazelle and our IWYU enforcement added several
bits of churn without any real benefit. The generated rules
also didn't help identify cases where we were not keeping tight
boundaries (e.g. non-gpu code and gpu code).
Identifying third_party deps automatically ended up being trickier
than anticipated (see the deleted //third_party/file_map_for_bazel.json)
Using the "maximum set of dependencies" worked ok, but ended up
increasing build time unnecessarily. For example, compiling
CanvasKit for WebGL always needed to compile Dawn because
SkSLCompiler.cpp sometimes needs to include tint/tint.h.
Follow-up CLs will rebuild the BUILD.bazel rules without gazelle.
Note to Reviewers:
- The only file worth manually reviewing here is bazel/Makefile.
Change-Id: I36d6fc3747487fabaf699690780c95f1f6765770
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543976
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
shaders.skia.org was passing in a Malloc'd TypedArray for uniforms
(to avoid unnecessary copying of that buffer on every frame).
However, CanvasKit would always take ownership of that buffer and
free it when the shader was freed. CanvasKit should only take
ownership (and clean up) the uniform buffer if it was not
copied into pre-malloc'd memory.
This also adds a handy make target that builds CanvasKit
and copies it into the proper place in the infra repository
to run the shaders app locally.
See also: https://skia-review.googlesource.com/c/buildbot/+/543436
Change-Id: I6c6b7f94f8c8571f9ce0613ccdd7fceb0f315a12
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/543416
Reviewed-by: Jorge Betancourt <jmbetancourt@google.com>
G3 prefers license() first.
This was done mechanically with a big find/replace
Change-Id: I8c33c7bc10a6bec42e966cad81c259954e841811
Bug: skia:13211
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535898
Reviewed-by: Ben Wagner <bungeman@google.com>
Ran the following commands:
find -name "BUILD.bazel" -exec sed -i -e '1iload("//bazel:macros.bzl", "cc_library", "exports_files_legacy")\nexports_files_legacy()' {} +
buildifier --lint=fix --mode=fix -r .
This had the effect of making sure we can export all of our
files in G3 (until we no longer have legacy targets) and
making all of our cc_libraries shim-able.
bazel/macros.bzl has the human-contributed changes, the rest
were mechanical.
Change-Id: I8e24e30e74b038cfd072cdbe4078bfd1d213dd46
Bug: skia:13211
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/535359
Reviewed-by: Ben Wagner <bungeman@google.com>
This removes the required dependency on our JSON code. In the Bazel
rules, this dependency is pushed down into sksl instead of required
by the cc_binary rules.
It adds a stub version of SkVMDebugTrace.cpp and removes
SkVMDebugTracePlayer unless the appropriate GN or Bazel flag
is set (skia_enable_sksl_tracing and enable_sksl_tracing,
respectively). There was an existing #define that CanvasKit
used (CK_INCLUDE_SKSL_TRACE) and this was changed to
SKSL_ENABLE_TRACING.
Users of //:skia_core no longer need to specify a JSON dep,
if sksl needs it (e.g. for tracing), then it will specify
the dependency.
This is a reland of https://skia-review.googlesource.com/c/skia/+/528837
Bug: skia:12541
Change-Id: I79612c69fdbefd3db9822a2b66df7552f7c13865
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529278
Reviewed-by: John Stiles <johnstiles@google.com>
This reverts commit 6bc4bdf645.
Reason for revert: Android roll
Original change's description:
> [sksl] Make sksl tracing optional
>
> This removes the required dependency on our JSON code. In the Bazel
> rules, this dependency is pushed down into sksl instead of required
> by the cc_binary rules.
>
> It adds a stub version of SkVMDebugTrace.cpp and removes
> SkVMDebugTracePlayer unless the appropriate GN or Bazel flag
> is set (skia_enable_sksl_tracing and enable_sksl_tracing,
> respectively). There was an existing #define that CanvasKit
> used (CK_INCLUDE_SKSL_TRACE) and this was changed to
> SKSL_ENABLE_TRACING.
>
> Users of //:skia_core no longer need to specify a JSON dep,
> if sksl needs it (e.g. for tracing), then it will specify
> the dependency.
>
> Change-Id: I2fcd29cde118fc391c269ba2d8f8a40a6f164c99
> Bug: skia:12541
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528837
> Reviewed-by: John Stiles <johnstiles@google.com>
> Commit-Queue: Kevin Lubick <kjlubick@google.com>
Bug: skia:12541
Change-Id: Icf75495f19e409d96925ca4dca9e839eca4057ec
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/529129
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
This removes the required dependency on our JSON code. In the Bazel
rules, this dependency is pushed down into sksl instead of required
by the cc_binary rules.
It adds a stub version of SkVMDebugTrace.cpp and removes
SkVMDebugTracePlayer unless the appropriate GN or Bazel flag
is set (skia_enable_sksl_tracing and enable_sksl_tracing,
respectively). There was an existing #define that CanvasKit
used (CK_INCLUDE_SKSL_TRACE) and this was changed to
SKSL_ENABLE_TRACING.
Users of //:skia_core no longer need to specify a JSON dep,
if sksl needs it (e.g. for tracing), then it will specify
the dependency.
Change-Id: I2fcd29cde118fc391c269ba2d8f8a40a6f164c99
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528837
Reviewed-by: John Stiles <johnstiles@google.com>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Change-Id: I238d29ba0250224fa593845ae65192653f58faff
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528156
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Change-Id: I337aebf72715339ec0280bab0916968ccbe7f481
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/528516
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
This also adds a make target to build a release version of
the debugger, which is handy when we want to push a fix
quickly. The make targets will also create the local_build
folder in the infra repo if it does not exist.
Change-Id: I073615a35068c425608454311a51c0c4e0a8152a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/527181
Reviewed-by: Brian Osman <brianosman@google.com>
Pardon the duplicate test file, I have not yet finished
moving the CanvasKit tests to be on Bazel. When I do,
the duplicate (font.spec.js) will go away.
Change-Id: I6ad468f3f322280ffa25429fb8732e7266703e91
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/526297
Reviewed-by: Ben Wagner <bungeman@google.com>
Bug: skia:12974
Change-Id: I15b090e2c3346d71ccf45d5f0d306da3f079821e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/523996
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Greg Daniel <egdaniel@google.com>
Bumps [karma](https://github.com/karma-runner/karma) from 6.3.2 to 6.3.16.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a href="https://github.com/karma-runner/karma/releases">karma's releases</a>.</em></p>
<blockquote>
<h2>v6.3.16</h2>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.15...v6.3.16">6.3.16</a> (2022-02-10)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>security:</strong> mitigate the "Open Redirect Vulnerability" (<a href="ff7edbb2ff">ff7edbb</a>)</li>
</ul>
<h2>v6.3.15</h2>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.14...v6.3.15">6.3.15</a> (2022-02-05)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>helper:</strong> make mkdirIfNotExists helper resilient to concurrent calls (<a href="d9dade2f00">d9dade2</a>), closes <a href="https://github-redirect.dependabot.com//github-redirect.dependabot.com/karma-runner/karma-coverage/issues/434/issues/issuecomment-1017939333">karma-runner/karma-coverage#434</a></li>
</ul>
<h2>v6.3.14</h2>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.13...v6.3.14">6.3.14</a> (2022-02-05)</h2>
<h3>Bug Fixes</h3>
<ul>
<li>remove string template from client code (<a href="91d5acda63">91d5acd</a>)</li>
<li>warn when <code>singleRun</code> and <code>autoWatch</code> are <code>false</code> (<a href="69cfc763c8">69cfc76</a>)</li>
<li><strong>security:</strong> remove XSS vulnerability in <code>returnUrl</code> query param (<a href="839578c45a">839578c</a>)</li>
</ul>
<h2>v6.3.13</h2>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.12...v6.3.13">6.3.13</a> (2022-01-31)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>deps:</strong> bump log4js to resolve security issue (<a href="5bf2df3044">5bf2df3</a>), closes <a href="https://github-redirect.dependabot.com/karma-runner/karma/issues/3751">#3751</a></li>
</ul>
<h2>v6.3.12</h2>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.11...v6.3.12">6.3.12</a> (2022-01-24)</h2>
<h3>Bug Fixes</h3>
<ul>
<li>remove depreciation warning from log4js (<a href="41bed33bf4">41bed33</a>)</li>
</ul>
<h2>v6.3.11</h2>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.10...v6.3.11">6.3.11</a> (2022-01-13)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>deps:</strong> pin colors package to 1.4.0 due to security vulnerability (<a href="a5219c52e2">a5219c5</a>)</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/karma-runner/karma/blob/master/CHANGELOG.md">karma's changelog</a>.</em></p>
<blockquote>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.15...v6.3.16">6.3.16</a> (2022-02-10)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>security:</strong> mitigate the "Open Redirect Vulnerability" (<a href="ff7edbb2ff">ff7edbb</a>)</li>
</ul>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.14...v6.3.15">6.3.15</a> (2022-02-05)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>helper:</strong> make mkdirIfNotExists helper resilient to concurrent calls (<a href="d9dade2f00">d9dade2</a>), closes <a href="https://github-redirect.dependabot.com//github-redirect.dependabot.com/karma-runner/karma-coverage/issues/434/issues/issuecomment-1017939333">karma-runner/karma-coverage#434</a></li>
</ul>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.13...v6.3.14">6.3.14</a> (2022-02-05)</h2>
<h3>Bug Fixes</h3>
<ul>
<li>remove string template from client code (<a href="91d5acda63">91d5acd</a>)</li>
<li>warn when <code>singleRun</code> and <code>autoWatch</code> are <code>false</code> (<a href="69cfc763c8">69cfc76</a>)</li>
<li><strong>security:</strong> remove XSS vulnerability in <code>returnUrl</code> query param (<a href="839578c45a">839578c</a>)</li>
</ul>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.12...v6.3.13">6.3.13</a> (2022-01-31)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>deps:</strong> bump log4js to resolve security issue (<a href="5bf2df3044">5bf2df3</a>), closes <a href="https://github-redirect.dependabot.com/karma-runner/karma/issues/3751">#3751</a></li>
</ul>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.11...v6.3.12">6.3.12</a> (2022-01-24)</h2>
<h3>Bug Fixes</h3>
<ul>
<li>remove depreciation warning from log4js (<a href="41bed33bf4">41bed33</a>)</li>
</ul>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.10...v6.3.11">6.3.11</a> (2022-01-13)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>deps:</strong> pin colors package to 1.4.0 due to security vulnerability (<a href="a5219c52e2">a5219c5</a>)</li>
</ul>
<h2><a href="https://github.com/karma-runner/karma/compare/v6.3.9...v6.3.10">6.3.10</a> (2022-01-08)</h2>
<h3>Bug Fixes</h3>
<ul>
<li><strong>logger:</strong> create parent folders if they are missing (<a href="0d24bd937f">0d24bd9</a>), closes <a href="https://github-redirect.dependabot.com/karma-runner/karma/issues/3734">#3734</a></li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="ab4b32898b"><code>ab4b328</code></a> chore(release): 6.3.16 [skip ci]</li>
<li><a href="ff7edbb2ff"><code>ff7edbb</code></a> fix(security): mitigate the "Open Redirect Vulnerability"</li>
<li><a href="c1befa04b3"><code>c1befa0</code></a> chore(release): 6.3.15 [skip ci]</li>
<li><a href="d9dade2f00"><code>d9dade2</code></a> fix(helper): make mkdirIfNotExists helper resilient to concurrent calls</li>
<li><a href="653c762be4"><code>653c762</code></a> ci: prevent duplicate CI tasks on creating a PR</li>
<li><a href="c97e562319"><code>c97e562</code></a> chore(release): 6.3.14 [skip ci]</li>
<li><a href="91d5acda63"><code>91d5acd</code></a> fix: remove string template from client code</li>
<li><a href="69cfc763c8"><code>69cfc76</code></a> fix: warn when <code>singleRun</code> and <code>autoWatch</code> are <code>false</code></li>
<li><a href="839578c45a"><code>839578c</code></a> fix(security): remove XSS vulnerability in <code>returnUrl</code> query param</li>
<li><a href="db53785b3e"><code>db53785</code></a> chore(release): 6.3.13 [skip ci]</li>
<li>Additional commits viewable in <a href="https://github.com/karma-runner/karma/compare/v6.3.2...v6.3.16">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/google/skia/network/alerts).
</details>
This is an imported pull request from
https://github.com/google/skia/pull/95
GitOrigin-RevId: ae940f93cbf5ebba6d02f722e0c9bc44f49c35c5
Change-Id: Ic9abd882cba29cdd130d5811f7c56fdfae9290de
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/514659
Reviewed-by: Ravi Mistry <rmistry@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
This CL makes a copy of all the files in
//modules/canvaskit/tests/ and puts them into
//modules/canvaskit/tests/bazel. They are slightly modified
to run in Bazel (renamed to be more clear what they are
and using EverythingLoaded instead of CanvasKitLoaded).
The original files will be deleted when we no longer test
CanvasKit outside of Bazel.
Suggested Review Order:
- hello_world.js is now smoke_test.js. That test polls the
gold_test_env server, but does not create an image.
- test_reporter.js which is much simplified from the non-Bazel
version (due to the removal of a bunch of PathKit stuff).
These JS tests are not the C++ gms. This means that we need
to capture the PNG ourselves, which we do using the <canvas>
API toDataURL(). This is base64 encoded, which is conveniently
the format accepted by the gold_test_env server.
- karma.bazel.js and assets/BUILD.bazel which make all the
test assets available under a shortened path /assets.
- Feel free to skip over the remaining *_test.js, as they are
basically the same as what is currently checked in, just
with the modifications above.
- Any remaining files.
Change-Id: I45fc38da38faf11f21011e7381d390e6bb299df4
Bug: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/513916
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
Reviewed-by: Ben Wagner <bungeman@google.com>
In order to extract the PNG files produced by our CanvasKit gms,
we need our JS tests to POST them to a server which can write to
disk. The easiest way to do this is to use the test_on_env
rule defined in the Skia Infra repo for exactly this purpose.
This required https://skia-review.googlesource.com/c/buildbot/+/510717
to be able to configure the binary correctly and
https://skia-review.googlesource.com/c/buildbot/+/511862, for nicer
debugging so the skia-infra dep was updated via the following commands:
$ go get go.skia.org/infra@d8a552a29e
$ go mod download
$ make -C infra/bots train
$ make -C bazel gazelle_update_repo
This caused many automated changes to infra/bots/tasks.json
The flow is:
1. User types bazelisk test :hello_world_test_with_env
2. The test_on_env rule starts gold_test_env and waits
for the file defined in $ENV_READY_FILE to be created.
3. gold_test_env starts a web server on a random port. It
writes this port number to $ENV_DIR/port. Then, it
creates $ENV_READY_FILE to signal ready.
4. test_on_env sees the ready file and then starts the
karma_test rule. (Reminder: this is a bash script
which starts karma using the Bazel-bundled chromium).
5. The karma_test rule runs the karma.bazel.js file (which
has been injected with some JS code to fill in Bazel
paths and settings) using Bazel-bundled node. This reads
in the port file and sets up a Karma proxy to redirect
/gold_rpc/report to http://localhost:PORT/report
6. The JS tests run via Karma (and do assertions via Jasmine).
Some tests, the gms, make POST requests to the proxy.
7. gold_test_env gets these POST requests writes the images
to a special Bazel folder on disk as defined by
$TEST_UNDECLARED_OUTPUTS_DIR.
8. test_on_env identifies that the tests finish (because the
karma_test script returns 0). It sends SIGINT to gold_test_env.
9. gold_test_env stops the webserver. The special Bazel folder
will zip up anything inside it and make it available for
future rules (e.g. a rule that will upload to Gold via goldctl).
Suggested Review Order:
- bazel/karma_test.bzl to see the test_on_env rule bundled into
the karma_test macro. I chose to put it there because it might
be confusing to have to define both a karma_test and test_on_env
rule in the same package but not be able to call one because it
will fail to talk to the server.
- gold_test_env.go to see how the appropriate files are written
to signal the environment is ready and the handlers are set up.
- karma.bazel.js to see how we make our own proxy given the
port from the env binary. The fact that we could not create
our own proxy with the existing karma_test rule was why the
chain ending in https://skia-review.googlesource.com/c/skia/+/508797
had to be abandoned.
- tests/*.js to see how the environment is probed via /healthz
and then used to make POST requests with data.
- Everything else.
Change-Id: I32a90def41796ca94cf187d640cfff8e262f85f6
BUG: skia:12541
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/510737
Reviewed-by: Leandro Lovisolo <lovisolo@google.com>
