[
https://issues.apache.org/jira/browse/KUDU-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125001#comment-17125001
]
Grant Henke commented on KUDU-2715:
-----------------------------------
The current list of failing tests in my MacOS environment are:
{code}
12 - client-test.0 (Failed)
15 - client-test.3 (Failed)
77 - fs_manager-test (Failed)
149 - master_authz-itest.4 (Failed)
152 - master_authz-itest.7 (Failed)
195 - tablet_server_quiescing-itest (Failed)
236 - rpc-test.1 (Failed)
238 - rpc-test.3 (Failed)
240 - rpc-test.5 (Failed)
242 - rpc-test.7 (Failed)
253 - webserver-test (Failed)
265 - compaction-test (Failed)
319 - kudu-tool-test.1 (Failed)
339 - tablet_server-test.3 (Failed)
366 - file_cache-stress-test (Failed)
391 - socket-test (Failed)
418 - trace-test (Failed)
{code}
> Get all tests passing on macOS
> ------------------------------
>
> Key: KUDU-2715
> URL: https://issues.apache.org/jira/browse/KUDU-2715
> Project: Kudu
> Issue Type: Bug
> Components: test
> Affects Versions: 1.9.0
> Reporter: Adar Dembo
> Priority: Major
>
> It seems that there are always a handful of tests that don't pass when run on
> macOS, though precisely which set depends on the underlying version of macOS.
> This taxes the release vote process, wherein macOS-based Kudu developers are
> forced to figure out whether the test failures they're seeing are "known
> issues" or indicative of problems with the release. Not to mention the
> day-to-day process of developing on macOS, where you never quite know whether
> your local work regressed a test, or whether that test was broken all along.
> In the past we looked into macOS CI builds and found the situation to be
> fairly bleak. Hopefully things have improved since then, but if not, I think
> we should still get the tests passing uniformly (disabling those which make
> no sense) and work in an ad hoc fashion towards keeping them that way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
