Install OMC for Jenkins in the most problematic paths

[Francesco Casella]

OMC has always been plagued by issues in the installation and working directory path, as soon as it contains spaces and non-ASCII characters, which happens very frequently under Windows, where Program Files is the norm for the former and Documents and Settings is often the norm for the latter, not to mention usernames with spaces, accented or cyrillic characters. There are dozens (hundreds?) of scripts being run by OMC on various occasions that can go wrong because of this, not to mention related tools such as OMNotebook, OMSens, OMSimulator, etc.

We already took the decision to support all those cases, see #4504, so we should test this systematically.

I would suggest that we install the Windows testing machine on a directory such as

c:\Program Files\OpenModelica1.16.0-dev-64bit\

and set the default temp directory to something like

c:\Temp\Users\Martin Sjölund\

so that we make sure everything works in those potentially critical case.

[Adrian Pop]

We don't install anything in Jenkins. We just use mos scripts to run tests.

Also, these issues are currently problematic:

• windows builds/tests are only done a priory via a special label
• we have a lot of tests that currently fail on Windows

We will need to do something about these (check them one by one) and also add some tests in which we *simulate* an installation and working directory in paths with spaces and special chars.

Is rather easy to do via mklink /J path/with/spaces/and/special/chars/link Target
This is how I tested #5804.

[Francesco Casella]

Replying to adrpo:

We don't install anything in Jenkins.

Aha.

Shouldn't we also test the installation process itself?

We just use mos scripts to run tests.

Also, these issues are currently problematic:

• windows builds/tests are only done a priory via a special label
• we have a lot of tests that currently fail on Windows

Can you be more specific, e.g. provide links to reports?

We will need to do something about these (check them one by one) and also add some tests in which we *simulate* an installation and working directory in paths with spaces and special chars.

Yeah, see above.

Is rather easy to do via mklink /J path/with/spaces/and/special/chars/link Target
This is how I tested #5804.

We can do this after 1.15.0 is rolled out (any news?)

[Martin Sjölund]

One problem is the test scripts assume we build into the build/ directory, and I believe the Jenkins workspace replaces spaces with underscores. And the checkout directory for git is also given.

I suppose we could change the build directory and make sure rtest/runtests.jl can be passed a flag for this.

[Adrian Pop]

When creating pull requests one needs to add "CI/Build MINGW" label to also run it on Windows:
​https://github.com/OpenModelica/OpenModelica/pulls
If the "CI/Build MINGW" label is not specified the Windows build/test is done after the commit to the master. However, even so, one needs to check the tests manually as only if the compilation fails the Job will fail.

Current windows test failures:
​https://test.openmodelica.org/jenkins/job/Windows/job/OM_Win/lastCompletedBuild/testReport/

[Francesco Casella]

Replying to adrpo:

Current windows test failures:
​https://test.openmodelica.org/jenkins/job/Windows/job/OM_Win/lastCompletedBuild/testReport/

Wow, there are quite some! I looked at a few, it seems to me that the problem is that reference results (e.g. log messages) have not been kept updated, rather than the tests actually failing, see, e.g. ​this report. Do I miss something?

I'm afraid that if success of these tests is not mandatory to merge the PR, this drift effect is inevitable, ultimately making the testsuite obsolete and worthless. In fact, who cares about it as of today?

Should we add this to the core testsuite, or is it going to be too slow? I guess it could run on a separate machine.

[Martin Sjölund]

Problems include:

• Expected results are the Linux results. Windows produces different results, logs, etc in many cases
• Windows simulations either hang or take longer than 15 minutes
• Running the Windows test suite takes ages and ages and ages and ages (the job takes >5 hours to run)
• The Windows omc.exe does not run under wine since we started using Boehm GC (would allow us to run the test suite faster)

[Adrian Pop]

All these tests are *working* in Linux but they fail in some way on Windows.
The test you pointed to:​here fails with Alarm Clock which means it failed to finish in 6 minutes or so.

I take a look at them from time to time and see if I can fix some of them.

The windows builds/tests are ran on different machines but it takes 2-5 hours instead of 30 minutes for Linux:
​https://test.openmodelica.org/jenkins/job/Windows/job/OM_Win/buildTimeTrend
Is also fairly unreliable, sometimes it hangs and one has to manually kill it.

I think we should have just some selected tests for Windows to test it works, building omc doesn't take that long, maybe 30 minutes. Of course these should include the tests for the special chars and spaces in paths. I will look into this after 1.15 is out and the change to clang, maybe it becomes more reliable and faster so that we could use it prior to each commit.

[Francesco Casella]

Replying to adrpo:

All these tests are *working* in Linux but they fail in some way on Windows.
The test you pointed to:​here fails with Alarm Clock which means it failed to finish in 6 minutes or so.

Which is kind of weird, the Lotka-Volterra model is really tiny, why should it take so much time?

The windows builds/tests are ran on different machines but it takes 2-5 hours instead of 30 minutes for Linux:
​https://test.openmodelica.org/jenkins/job/Windows/job/OM_Win/buildTimeTrend
Is also fairly unreliable, sometimes it hangs and one has to manually kill it.

Too bad. I almost always run OMC from Windows, but on individual models I never had such problems (except gcc being much slower than clang to compile)

I think we should have just some selected tests for Windows to test it works, building omc doesn't take that long, maybe 30 minutes. Of course these should include the tests for the special chars and spaces in paths.

Sounds good!

I will look into this after 1.15 is out and the change to clang, maybe it becomes more reliable and faster so that we could use it prior to each commit.

OK, thanks!

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Rescheduled to 1.18.0

[Francesco Casella]

Ticket retargeted after milestone closed

[Francesco Casella]

1.18.0 blocker tickets moved to 1.19.0