Checkout failed in functional tests on AppVeyor

[Jun Omae]

It seems functional tests on AppVeyor only for x86 failed. The tests passed for x64.

[00:02:27] python trac/tests/functional/__init__.py 
[00:02:29] SKIP: validation of XHTML output in functional tests (no lxml installed)
[00:02:29] make.exe : Traceback (most recent call last):
[00:02:29] At C:\projects\trac\contrib\appveyor.ps1:376 char:9
[00:02:29] +         & make.exe $goal 2>&1 | Tee-Object -Variable make
[00:02:29] +         ~~~~~~~~~~~~~~~~~~~~~
[00:02:29]     + CategoryInfo          : NotSpecified: (Traceback (most recent call last)::String) [], RemoteException
[00:02:29]     + FullyQualifiedErrorId : NativeCommandError
[00:02:29]  
[00:02:29]   File "trac/tests/functional/__init__.py", line 221, in <module>
[00:02:29]     unittest.main(defaultTest='suite')
[00:02:29]   File "C:\Python27\lib\unittest\main.py", line 95, in __init__
[00:02:29]     self.runTests()
[00:02:29]   File "C:\Python27\lib\unittest\main.py", line 232, in runTests
[00:02:29]     self.result = testRunner.run(self.test)
[00:02:29]   File "C:\Python27\lib\unittest\runner.py", line 151, in run
[00:02:29]     test(result)
[00:02:29]   File "C:\Python27\lib\unittest\suite.py", line 70, in __call__
[00:02:29]     return self.run(*args, **kwds)
[00:02:29]   File "C:\Python27\lib\unittest\suite.py", line 108, in run
[00:02:29]     test(result)
[00:02:29]   File "C:\Python27\lib\unittest\suite.py", line 70, in __call__
[00:02:29]     return self.run(*args, **kwds)
[00:02:29]   File "C:\projects\trac\trac\test.py", line 223, in run
[00:02:29]     self.setUp()
[00:02:29]   File "trac/tests/functional/__init__.py", line 150, in setUp
[00:02:29]     self._testenv = self.env_class(env_path, port, baseurl)
[00:02:29]   File "C:\projects\trac\trac\tests\functional\testenv.py", line 78, in __init__
[00:02:29]     self.create()
[00:02:29]   File "C:\projects\trac\trac\tests\functional\testenv.py", line 139, in create
[00:02:29]     self.create_repo()
[00:02:29]   File "C:\projects\trac\trac\tests\functional\svntestenv.py", line 40, in create_repo
[00:02:29]     raise Exception('Checkout from %s failed.' % self.repo_url())
[00:02:29] Exception: Checkout from file:///C:/projects/trac/testenv/repo failed.

See ​https://ci.appveyor.com/project/edgewall-org/trac/build/1.0-stable.223.

[Christian Boos]

The testing.log shows:

svn: E170013: Unable to connect to a repository at URL 'file:///C:/projects/trac/testenv/repo'
svn: E180001: Unable to open repository 'file:///C:/projects/trac/testenv/repo'

Going there in the shell, it seems that this message is produced by svn 1.9.3 from C:/msys64/usr/bin. That version of svn expects local URLs in the form of file:///C/projects/....

It seems that we suddenly use that version instead of the one corresponding to the binding because the setup of the PATH is broken (maybe due the switch to make 4.1 and the way export works there?).

In the PowerShell, all seems fine:

PS C:\projects\trac> echo $env:PATH
C:\projects\dependencies\svn-win32-1.8.15\bin;;\Scripts;C:\msys64\usr\bin;C:\Perl\site\bin;C:\Perl\bin;C:\windows\system32;C:\windows;C:\windows\System32\Wbem;C:\windows\System32\WindowsPowerShell\v1.0\;C:\Program Files x86)\Google\Cloud...

Doing make status, slightly modified so that it shows the actual value of the PATH environment variable (I'll commit that change):

PATH=C:\Python27;C:\Python27/Scripts;;/c/projects/dependencies/svn-win32-1.8.15/bin:/c/Scripts:/usr/bin:/c/Perl/site/bin:/c/Perl/bin:/c/windows/system32:/c/windows:/c/windows/System32/Wbem:/c/windows/Syste...

And this mix of ; and : doesn't work well, if you look at the actual path from within the python process (os.environ['PATH']):

C;C:\Python27;C;C:\Python27\Scripts;;\c\projects\dependencies\svn-win32-1.8.15\bin;C:\Scripts;C:\msys64\usr\bin;C:\Perl\site\bin;C:\Perl\bin;C:\windows\system32;C:\windows;...

So the "correct" path to the svn binaries that we want to use is garbled, and the next svn binaries found are the msys64 ones, with this different URL convention.

Besides, the mysql56 service is no longer, it looks like there's only MySQL 5.7 x64 database service. I'll fix that as well.

[Christian Boos]

Should be fixed by r14760 and r14761, let's see…

[Christian Boos]

All is green again ;-)

Thanks for the watch, Jun!