test_parseconf.sh: apparently not reliable on Appveyor

For some reason, I'm seeing intermittent failure from test_parseconf on appveyor. Since we're close to a release, I think that for now I should make this test become allowed-to-fail on windows for now, and investigate it more after 0.4.2.1-alpha is released.

changed milestone to %Tor: unspecified in legacy/trac

added 042-should in Legacy / Trac asn-merge in Legacy / Trac component::core tor/tor in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac priority::high in Legacy / Trac reviewer::ahf in Legacy / Trac severity::normal in Legacy / Trac status::assigned in Legacy / Trac tor-ci in Legacy / Trac type::defect in Legacy / Trac labels

Trac:
Keywords: tor-ci deleted, tor-ci 042-must added

I have a temporary workaround in a branch called ticket31754_workaround; PR in https://github.com/torproject/tor/pull/1325

I'll put this in needs_review once CI has passed.

For reference, here is an example of a failing test:

ops_1: cmp: EOF on /tmp/tor_parseconf_tests.1JMUV6/output.ops_1 which is empty
FAIL
Sep 16 13:21:31.759 [notice] Tor 0.4.2.0-alpha-dev (git-804260828b13e76a) running on Windows Server 2016 [or later] with Libevent 2.1.11-stable, OpenSSL 1.1.1c, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.4.2.
Sep 16 13:21:31.759 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Sep 16 13:21:31.759 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Sep 16 13:21:31.760 [notice] Read configuration file "C:\msys64\tmp\tor_parseconf_tests.1JMUV6\EMPTY".
Sep 16 13:21:31.760 [notice] Read configuration file "C:\projects\tor\src\test\conf_examples\ops_1\torrc".
Sep 16 13:21:31.769 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\projects\tor\src\test\conf_examples\ops_1\<default>. Is this what you wanted?
Sep 16 13:21:31.769 [warn] Path for GeoIPv6File (<default>) is relative and will resolve to C:\projects\tor\src\test\conf_examples\ops_1\<default>. Is this what you wanted?
Sep 16 13:21:31.769 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Sep 16 13:21:31.769 [notice] Based on detected system memory, MaxMemInQueues is set to 3749 MB. You can override this by setting MaxMemInQueues by hand.
Sep 16 13:21:31.769 [notice] By default, Tor does not run as an exit relay. If you want to be an exit relay, set ExitRelay to 1. To suppress this message in the future, set ExitRelay to 0.
--- ./expected	2019-09-16 13:09:34.157535000 +0000
+++ /tmp/tor_parseconf_tests.1JMUV6/output.ops_1	2019-09-16 13:21:31.650950300 +0000
@@ -1,2 +0,0 @@
-Nickname Unnamed
-ORPort 1000
FAIL src/test/test_parseconf.sh (exit status: 1)

https://ci.appveyor.com/project/torproject/tor/builds/27439727/job/4n0mtcayea8jwria

Note that it is random which test fails, but the symptoms seem to be uniform: no actual error is logged, but the output file is empty.

Arg, the name of the branch was wrong. I've made a ticket31757_workaround with PR at https://github.com/torproject/tor/pull/1326 . Since this is a CI reliability issue, it can't hurt to let both CI runs finish.

PR looks good.

Trac:
Status: assigned to merge_ready
Reviewer: N/A to ahf

I've made a squashed branch as ticket31757_workaround_squashed . PR at https://github.com/torproject/tor/pull/1327

Trac:
Keywords: tor-ci 042-must deleted, tor-ci 042-must asn-merge added

Merged!

Trac:
Resolution: N/A to fixed
Status: merge_ready to closed

Reopening because the patch doesn't actually fix the test failure: it just makes the test failure not break the build on Windows.

Trac:
Resolution: fixed to N/A
Status: closed to reopened

Trac:
Status: reopened to accepted

Trac:
Keywords: tor-ci 042-must asn-merge deleted, tor-ci 042-should asn-merge added

This is a strange bug: we have other tests that run Tor on Windows:

PASS: src/test/test_zero_length_keys.sh
PASS: src/test/test_cmdline.sh

Are we doing something in the script that doesn't work with Tor on Windows? What's the smallest script that reproduces the issue?

Trac:
Status: accepted to assigned
Owner: nickm to ahf

No more sponsor 31. All this tickets remained open after sponsor 31 ended.

Trac:
Sponsor: Sponsor31-can to N/A

Trac:
Owner: ahf to N/A
Milestone: Tor: 0.4.2.x-final to Tor: unspecified

moved from legacy/trac#31757 (moved)

added Bug label and removed 1 deleted label

added CI label and removed 1 deleted label

removed milestone

added BugSmashFund label

We're no longer using appveyor, right? Closing.

closed