build(deps): bump handlebars from 4.0.11 to 4.5.3 in /ui #2
Conversation
This file contains 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
Change-Id: Idd5f8dc119a41c9692d3e4ce79b405da4ec10af2
Bumps [handlebars](https://github.com/wycats/handlebars.js) from 4.0.11 to 4.5.3. - [Release notes](https://github.com/wycats/handlebars.js/releases) - [Changelog](https://github.com/wycats/handlebars.js/blob/master/release-notes.md) - [Commits](handlebars-lang/handlebars.js@v4.0.11...v4.5.3) Signed-off-by: dependabot[bot] <[email protected]>
|
Looks like handlebars is up-to-date now, so this is no longer needed. |
Closed
Closed
primiano
pushed a commit
that referenced
this pull request
Feb 2, 2022
This specific problem has been discovered when running relatively short
chromium startup tracing sessions. On some of test devices we often hit
the following DCHECK in chromium codebase.
This specific race manifests itself by triggering the following DCHECK
[3882:3891:0126/115600.790166:3682185893:FATAL:trace_event_data_source.cc(1200)]
Check failed: TraceLog::GetInstance()->IsEnabled().
#0 0x0000036f50d8 base::debug::CollectStackTrace()
#1 0x0000036703b4 base::debug::StackTrace::StackTrace()
#2 0x00000367faa4 logging::LogMessage::~LogMessage()
#3 0x0000036802b0 logging::LogMessage::~LogMessage()
#4 0x00000366b66a logging::CheckError::~CheckError()
#5 0x0000039d6ec2 tracing::TraceEventDataSource::Flush()
#6 0x0000039d3b6c tracing::ProducerClient::Flush()
#7 0x0000039e2d28 tracing::mojom::ProducerClientStubDispatch::Accept()
When it happens not only TraceLog instance has been disabled. The
TraceEventDataSource::IsEnabled method also returns false. Basically
somebody tries to flush data source after it has been disabled.
The root cause for this can be traced back to perfetto's
TracingServiceImpl::StartTracing method. This method among other things
post a delayed task to call FlushAndDisableTracing if duration_ms config
key is non zero. Unfortunately this delayed callback does not take into
account that tracing could already be disabled when its invoked. This
can happen if somebody already called TracingServiceImpl::DisableTracing,
as is often the case in application shutdown process. If the delayed
callback is invoked in the middle of the shutdown procedure the extra
flush can potentially prompt the code to reach a state its not expected
to reach. In case of chromium this can trigger TraceEventDataSource
illustrated on the provided stack trace. This DCHECK is not simple to
reproduce since the TraceEventDataSource code runs in a different
process which often is also shutting down.
Since the code generally does not expect to call flush when tracing is
disabled, lets just make sure TracingServiceImpl::FLush does nothing if
tracing has has not been started.
Change-Id: Ie7944b004cfdff216199217da918ba614f3ff552
primiano
pushed a commit
that referenced
this pull request
Jan 12, 2023
TSAN reported the problem below on a CI run. There's a possible sequence of events that can lead to this race (I'm not sure it's the only one): * The perfetto SDK thread calls the OnStop callback. * The perfetto SDK thread is now inside WaitableTestEvent::Notify(). * The perfetto SDK thread sets notified_ to true and it unlocks the mutex, but does not call `cv_.notify_one()`. * The main thread executes `WaitableTestEvent::Wait()`, which at this point can return. * The main thread finishes executing the test and destroys the tracing sessions, which destroys the WaitableTestEvent and therefore `cv_`. * The perfetto SDK thread resumes execution and tries to execute `cv_.notify_one()`, but that races with `cv_` destructor. In order to prevent this race, we can just call `cv_.notify_one()` under the lock. It might be less efficient, but it's correct. This reverts part of https://r.android.com/1373304 https://ci.perfetto.dev/#!/logs/20221219192758--cls-2345694-4--linux-clang-x86_64-tsan ``` [00:07:40] [ RUN ] PerfettoApiTest/PerfettoApiTest.TrackEventObserver_TwoDataSources/System [00:07:40] [901.194] ing_service_impl.cc:980 Configured tracing session 1, #sources:1, duration:500 ms, #buffers:1, total buffer size:1024 KB, total sessions:1, uid:1337 session name: "" [00:07:41] [901.697] ng_service_impl.cc:1921 FlushAndDisableTracing(1) done, success=1 [00:07:41] [901.698] ing_service_impl.cc:980 Configured tracing session 2, #sources:1, duration:500 ms, #buffers:1, total buffer size:1024 KB, total sessions:2, uid:1337 session name: "" [00:07:41] [902.200] ng_service_impl.cc:1921 FlushAndDisableTracing(2) done, success=1 [00:07:42] ================== [00:07:42] WARNING: ThreadSanitizer: data race (pid=7841) [00:07:42] Write of size 8 at 0x7b2000019c40 by main thread: [00:07:42] #0 pthread_cond_destroy ??:? (perfetto_integrationtests+0x315f8d) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #1 std::Cr::condition_variable::~condition_variable() ??:? (libc++.so+0xad729) (BuildId: bea413d45487d5c2) [00:07:42] #2 (anonymous namespace)::PerfettoApiTest::TearDown() api_integrationtest.cc:? (perfetto_integrationtests+0x398609) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #3 testing::Test::Run() ??:? (perfetto_integrationtests+0x8de94f) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #4 testing::TestInfo::Run() ??:? (perfetto_integrationtests+0x8e0a2c) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #5 testing::TestSuite::Run() ??:? (perfetto_integrationtests+0x8e1b14) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #6 testing::internal::UnitTestImpl::RunAllTests() ??:? (perfetto_integrationtests+0x8f9e3f) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #7 testing::UnitTest::Run() ??:? (perfetto_integrationtests+0x8f8d36) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #8 main api_integrationtest_main.cc:? (perfetto_integrationtests+0x4d7aa4) (BuildId: 2d1df55c4bda2cdd) [00:07:42] [00:07:42] Previous read of size 8 at 0x7b2000019c40 by thread T3: [00:07:42] #0 pthread_cond_signal ??:? (perfetto_integrationtests+0x315c28) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #1 std::Cr::condition_variable::notify_one() ??:? (libc++.so+0xad479) (BuildId: bea413d45487d5c2) [00:07:42] #2 void std::Cr::__function::__policy_invoker<void ()>::__call_impl<std::Cr::__function::__default_alloc_func<(anonymous namespace)::PerfettoApiTest::NewTrace(perfetto::protos::gen::TraceConfig const&, perfetto::BackendType, int)::{lambda()#1}, void ()> >(std::Cr::__function::__policy_storage const*) api_integrationtest.cc:? (perfetto_integrationtests+0x39ba0a) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #3 perfetto::base::UnixTaskRunner::RunImmediateAndDelayedTask() unix_task_runner.cc:? (perfetto_integrationtests+0x594cfd) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #4 perfetto::base::UnixTaskRunner::Run() unix_task_runner.cc:? (perfetto_integrationtests+0x594133) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #5 perfetto::base::ThreadTaskRunner::RunTaskThread(std::Cr::function<void (perfetto::base::UnixTaskRunner*)>) thread_task_runner.cc:? (perfetto_integrationtests+0x592e4f) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #6 void* std::Cr::__thread_proxy[abi:v160000]<std::Cr::tuple<std::Cr::unique_ptr<std::Cr::__thread_struct, std::Cr::default_delete<std::Cr::__thread_struct> >, void (perfetto::base::ThreadTaskRunner::*)(std::Cr::function<void (perfetto::base::UnixTaskRunner*)>), perfetto::base::ThreadTaskRunner*, std::Cr::function<void (perfetto::base::UnixTaskRunner*)> > >(void*) thread_task_runner.cc:? (perfetto_integrationtests+0x59380b) (BuildId: 2d1df55c4bda2cdd) [00:07:42] [00:07:42] Location is heap block of size 120 at 0x7b2000019c00 allocated by main thread: [00:07:42] #0 operator new(unsigned long) ??:? (perfetto_integrationtests+0x3941a7) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #1 (anonymous namespace)::PerfettoApiTest::NewTrace(perfetto::protos::gen::TraceConfig const&, int) api_integrationtest.cc:? (perfetto_integrationtests+0x39b864) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #2 (anonymous namespace)::PerfettoApiTest::NewTraceWithCategories(std::Cr::vector<std::Cr::basic_string<char, std::Cr::char_traits<char>, std::Cr::allocator<char> >, std::Cr::allocator<std::Cr::basic_string<char, std::Cr::char_traits<char>, std::Cr::allocator<char> > > >, perfetto::protos::gen::TrackEventConfig, perfetto::protos::gen::TraceConfig) api_integrationtest.cc:? (perfetto_integrationtests+0x3a6385) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #3 (anonymous namespace)::PerfettoApiTest_TrackEventObserver_TwoDataSources_Test::TestBody() api_integrationtest.cc:? (perfetto_integrationtests+0x4a61d2) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #4 testing::Test::Run() ??:? (perfetto_integrationtests+0x8de8c3) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #5 testing::TestInfo::Run() ??:? (perfetto_integrationtests+0x8e0a2c) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #6 testing::TestSuite::Run() ??:? (perfetto_integrationtests+0x8e1b14) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #7 testing::internal::UnitTestImpl::RunAllTests() ??:? (perfetto_integrationtests+0x8f9e3f) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #8 testing::UnitTest::Run() ??:? (perfetto_integrationtests+0x8f8d36) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #9 main api_integrationtest_main.cc:? (perfetto_integrationtests+0x4d7aa4) (BuildId: 2d1df55c4bda2cdd) [00:07:42] [00:07:42] Thread T3 'TracingMuxer' (tid=7845, running) created by main thread at: [00:07:42] #0 pthread_create ??:? (perfetto_integrationtests+0x3147ab) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #1 perfetto::base::ThreadTaskRunner::ThreadTaskRunner(std::Cr::basic_string<char, std::Cr::char_traits<char>, std::Cr::allocator<char> > const&) thread_task_runner.cc:? (perfetto_integrationtests+0x592b80) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #2 perfetto::(anonymous namespace)::PlatformPosix::CreateTaskRunner(perfetto::Platform::CreateTaskRunnerArgs const&) platform_posix.cc:? (perfetto_integrationtests+0x8c524a) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #3 perfetto::internal::TracingMuxerImpl::TracingMuxerImpl(perfetto::TracingInitArgs const&) tracing_muxer_impl.cc:? (perfetto_integrationtests+0x5a731c) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #4 perfetto::internal::TracingMuxerImpl::InitializeInstance(perfetto::TracingInitArgs const&) tracing_muxer_impl.cc:? (perfetto_integrationtests+0x5ad7fb) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #5 perfetto::Tracing::InitializeInternal(perfetto::TracingInitArgs const&) tracing.cc:? (perfetto_integrationtests+0x5c0f0d) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #6 (anonymous namespace)::ConcurrentSessionTest_ConcurrentBackends_Test::TestBody() api_integrationtest.cc:? (perfetto_integrationtests+0x4c3af4) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #7 testing::Test::Run() ??:? (perfetto_integrationtests+0x8de8c3) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #8 testing::TestInfo::Run() ??:? (perfetto_integrationtests+0x8e0a2c) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #9 testing::TestSuite::Run() ??:? (perfetto_integrationtests+0x8e1b14) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #10 testing::internal::UnitTestImpl::RunAllTests() ??:? (perfetto_integrationtests+0x8f9e3f) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #11 testing::UnitTest::Run() ??:? (perfetto_integrationtests+0x8f8d36) (BuildId: 2d1df55c4bda2cdd) [00:07:42] #12 main api_integrationtest_main.cc:? (perfetto_integrationtests+0x4d7aa4) (BuildId: 2d1df55c4bda2cdd) [00:07:42] [00:07:42] SUMMARY: ThreadSanitizer: data race ??:? in __interceptor_pthread_cond_destroy [00:07:42] ================== ``` Change-Id: Ic822dba258b81a6c032633cf63763bd578739024
primiano
pushed a commit
that referenced
this pull request
Jul 3, 2024
Kernel stalls during a critical path traversal could lead to unexpected results. The expected behavior is that the critical path should resume from the thread where the stall was first encountered. This wasn't the case, the critical path would naively follow the kernel stall until the entire critical path interval regions has been resolved. The new algorithm solves this in 3 phases: 1. Critical path following only userspace edges, i.e if a kernel node is encountered, we jump to the prev_node instead of the waker_node. This has the effect of staying on the thread when a kernel stall is encountered. 2. Another critical path with the kernel nodes encountered from #1 as roots. This has the effect of filling the kernel stall gaps from 3. Flatten the intervals from the results of #1 and #2. Where any interval in #2 is a child of the resulting interval from #1. Fixed a small omission in the _intervals_to_roots macro where it wasn't correctly bounded to a utid. It didn't affect correctness since we post-filtered utid, but it affected performance. Also removed a special case for IRQs. Prevoiusly, we skipped them because we didn't have process attribution, this means they were not present in the wakeup_graph and we couldn't easily answer questions like what part of the critical path was stalled in an IRQ? Now, we don't skip them, we simply follow their 'prev' edge, hence staying on the same thread, since we still don't have process attribution. With this change, we have information about nodes that were stalled waiting on an IRQ, even if we don't have any further information about the IRQ. Test: tools/diff_test_trace_processor.py out/android/trace_processor_shell --name-filter '.*thread_executing_span.*' Change-Id: I0a451fbc218c2e1ae775eccd2e9966a69d1008a8
primiano
pushed a commit
that referenced
this pull request
Sep 17, 2024
Some of our integration tests are randomly failing in CI with:
```
[00:16:35] [ RUN ] Run/HeapprofdEndToEnd.ConcurrentSession/StaticModeCustom
[00:16:35] [810.227] approfd_producer.cc:255 Disconnected from tracing service
[00:16:35] [810.428] approfd_producer.cc:255 Disconnected from tracing service
[00:16:35] [810.473] ng_service_impl.cc:1125 Configured tracing session 1, #sources:1, duration:5000 ms, #buffers:1, total buffer size:10240 KB, total sessions:1, uid:1337 session name: ""
[00:16:35] [810.829] approfd_producer.cc:245 Connected to the service, mode [child].
[00:16:35] [810.830] approfd_producer.cc:367 Setting up datasource: non-statsd initiator.
[00:16:36] [811.472] end_to_end_test.cc:1706 Starting concurrent.
[00:16:36] [811.473] paged_memory.cc:69 PERFETTO_CHECK(ptr && ptr != MAP_FAILED) (errno: 12, Cannot allocate memory)
[00:16:36]
[00:16:36] -----BEGIN PERFETTO PRE-CRASH LOG-----
[00:16:36] trace_uuid: ccd77e58-4684-4fcd-ce84-d54022f
[00:16:36] [810.079] ng_service_impl.cc:2102 FlushAndDisableTracing(2) done, success=1
[00:16:36] [810.139] _end_to_end_test.cc:726 Stats for 16809: unwinding_errors: 0?heap_samples: 198?map_reparses: 0?unwinding_time_us: [-inf, 1]: 0; [1, 2]: 0; [2, 4]: 0; [4, 8]: 0; [8, 16]: 98; [16, 32]: 96; [32, 64]: 3; [64, 128]: 0; [128, 256]: 0; [256, 512]: 0;
[00:16:36] [810.139] _end_to_end_test.cc:842 Shutting down profile target.
[00:16:36] [810.147] ng_service_impl.cc:2713 Tracing session 2 ended, total sessions:1
[00:16:36] [810.156] ng_service_impl.cc:2713 Tracing session 1 ended, total sessions:0
[00:16:36] [810.473] ng_service_impl.cc:1125 Configured tracing session 1, #sources:1, duration:5000 ms, #buffers:1, total buffer size:10240 KB, total sessions:1, uid:1337 session name: ""
[00:16:36] [811.472] end_to_end_test.cc:1706 Starting concurrent.
[00:16:36] [811.473] paged_memory.cc:69 PERFETTO_CHECK(ptr && ptr != MAP_FAILED) (errno: 12, Cannot allocate memory)
[00:16:36]
[00:16:36] -----END PERFETTO PRE-CRASH LOG-----
[00:16:36] [811.661] approfd_producer.cc:255 Disconnected from tracing service
[00:16:36] test/ci/linux_tests.sh: line 32: 16041 Illegal instruction (core dumped) ${OUT_PATH}/perfetto_integrationtests
```
It turns out this as little to do with heapprofd, it's just that mmap is
not able to allocate memory in trace_processor most of the times:
```
[00:02:56] AddressSanitizer: CHECK failed: sanitizer_common.cpp:61 "((0 && "unable to mmap")) != (0)" (0x0, 0x0) (tid=13072)
[00:02:56] #0 0x56e38cb2 in __asan::CheckUnwind() /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_rtl.cpp:69:3
[00:02:56] #1 0x56e4d5bb in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:86:5
[00:02:56] #2 0x56e3f580 in __sanitizer::ReportMmapFailureAndDie(unsigned int, char const*, char const*, int, bool) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/sanitizer_common/sanitizer_common.cpp:61:3
[00:02:56] #3 0x56e4640b in __sanitizer::MmapOrDieOnFatalError(unsigned int, char const*) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/sanitizer_common/sanitizer_posix.cpp:74:5
[00:02:56] #4 0x56da6fdd in __sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback, __sanitizer::LargeMmapAllocatorPtrArrayStatic, __sanitizer::LocalAddressSpaceView>::Allocate(__sanitizer::AllocatorStats*, unsigned int, unsigned int) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_secondary.h:98:9
[00:02:56] #5 0x56da6e19 in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator32<__asan::AP32<__sanitizer::LocalAddressSpaceView>>, __sanitizer::LargeMmapAllocatorPtrArrayStatic>::Allocate(__sanitizer::SizeClassAllocator32LocalCache<__sanitizer::SizeClassAllocator32<__asan::AP32<__sanitizer::LocalAddressSpaceView>>>*, unsigned int, unsigned int) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/../sanitizer_common/sanitizer_allocator_combined.h:71:24
[00:02:56] #6 0x56da2b5b in __asan::Allocator::Allocate(unsigned int, unsigned int, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_allocator.cpp:582:29
[00:02:56] #7 0x56da3668 in __asan::asan_memalign(unsigned int, unsigned int, __sanitizer::BufferedStackTrace*, __asan::AllocType) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_allocator.cpp:1060:16
[00:02:56] #8 0x56e657a7 in operator new(unsigned int) /b/s/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_new_delete.cpp:86:3
[00:02:56] #9 0xf7dc6a49 in void* std::__Cr::__libcpp_operator_new<unsigned int>(unsigned int) /ci/ramdisk/src/out/dist/../../buildtools/libcxx/include/new:270:10
[00:02:56] #10 0xf7dc6a49 in std::__Cr::__libcpp_allocate(unsigned int, unsigned int) /ci/ramdisk/src/out/dist/../../buildtools/libcxx/include/new:294:10
[00:02:56] #11 0xf7dc6a49 in std::__Cr::allocator<char>::allocate(unsigned int) /ci/ramdisk/src/out/dist/../../buildtools/libcxx/include/__memory/allocator.h:119:32
[00:02:56] #12 0xf7dc6a49 in std::__Cr::__allocation_result<std::__Cr::allocator_traits<std::__Cr::allocator<char>>::pointer> std::__Cr::__allocate_at_least<std::__Cr::allocator<char>>(std::__Cr::allocator<char>&, unsigned int) /ci/ramdisk/src/out/dist/../../buildtools/libcxx/include/__memory/allocate_at_least.h:41:19
[00:02:56] #13 0xf7dc6a49 in std::__Cr::basic_string<char, std::__Cr::char_traits<char>, std::__Cr::allocator<char>>::__grow_by(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) /ci/ramdisk/src/out/dist/../../buildtools/libcxx/include/string:2426:23
```
I've looked at the virtual address space and it's very fragmented, the
ASAN allocator seems to leave around a lot of 1MB sections.
I'm assuming that ASAN on 32-bit devices is harder to support because of
the limited amount of address space.
We don't really need 32-bit coverage for ASAN, we have 64-bit coverage
for ASAN (and 32-bit ASAN on android is becoming less relevant with
HWASAN).
Let's use this configuration to have some coverage for a 32-bit build.
Change-Id: I02ed354757874dd51b0c1c2b739d91e3c6584119
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Bumps handlebars from 4.0.11 to 4.5.3.
Changelog
Sourced from handlebars's changelog.
Commits
c819c8bv4.5.3827c9d0Update release notesf7f05d7fix: add "no-prototype-builtins" eslint-rule and fix all occurences1988878fix: add more properties required to be enumerable886ba86test/chore: add chai/expect and sinon to "runtime"-environment0817dadtest: add sinon as global variable to eslint in the specs93516a0test: add sinon.js for spies, deprecate current assertions93e284echore: add chai and dirty-chai for better test assertionsc02b05ffix: use !== 0 instead of != 08de121dv4.5.2Dependabot 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 commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot ignore this [patch|minor|major] versionwill close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill 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 labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill set the current milestone as the default for future PRs for this repo and languageYou can disable automated security fix PRs for this repo from the Security Alerts page.