Enable Windows builds on Azure Pipelines

[taketwo]

No description provided.

[UnaNancyOwen]

If Azure Pipelines has not time-limit per job, outofcore (tests_outofcore) and visualization (tests_visualization) testing may be possible. Please consider to add vcpkg install vtk and boost-property-map, boost-uuid,

[UnaNancyOwen]

tools may not be necessary for tests. (-DBUILD_tools=OFF)
surface_on_nurbus may need to be tested. (-DBUILD_surface_on_nurbs=ON)

[UnaNancyOwen]

I think CMake creates an x86 project by default under Windows. Therefore, the case of x64 has failed.
It is need specify generator by target architecture.

# In case of x86
cmake -G "Visual Studio 15 2017"
# In case of x64
cmake -G "Visual Studio 15 2017 Win64"

[taketwo]

If Azure Pipelines has not time-limit per job, visualization (test_visualization) testing may be possible.

It would be nice to enable visualization build as well. I'm concerned with the build time though. Yes, there is no limit on Azure, however we probably don't want our pipelines to take forever to build. There is no caching, so vcpkg has to install everything from scratch every time. Right now (without vtk) it already takes 20 minutes to install the dependencies, plus another 2 hours for the library build. I'm afraid adding vtk can add another 30-40 minutes. But yeah, once the pipeline is working I'll give it a try to know the exact numbers and then we can decide if we enable it or not.

It is need specify generator by target architecture.

Thanks for the suggestion. This would explain why x64 build failed immediately.

The x86 build succeeded, however most tests failed with obscure **Exception: Exit code 0xc0000135. Do you have any idea what this could mean?

[SergioRAgostinho]

Do you have any idea what this could mean?

Could it be that the path to the test files is somehow incorrect? If you notice, it's always tests which take files as command line arguments.

[UnaNancyOwen]

There is no caching, so vcpkg has to install everything from scratch every time.

It is mean there is no cache feature in Azure Pipelines?
@kaylangan She may know good ideas and information.

[UnaNancyOwen]

Do you have any idea what this could mean?

Please try to turn on VCPKG_APPLOCAL_DEPS. (-DVCPKG_APPLOCAL_DEPS=ON)

[UnaNancyOwen]

If you don't use ninja-build, it is unnecessary to specify them explicitly.

-DCMAKE_C_COMPILER=cl.exe
-DCMAKE_CXX_COMPILER=cl.exe

[taketwo]

If you don't use ninja-build, it is unnecessary to specify them explicitly.

I tried without yesterday, but ended up with GCC 5 being picked up as a compiler. However, now I understand that it was because I did not set "Visual Studio 15 2017" as a generator.

Please try to turn on VCPKG_APPLOCAL_DEPS

Will add with next commit.

[taketwo]

Could it be that the path to the test files is somehow incorrect? If you notice, it's always tests which take files as command line arguments.

There is at least one test that uses files and succeeded:

100: Test command: D:\a\build\bin\test_random_walker.exe "D:/a/1/s/test/segmentation/data"

Also there are lots of tests that don't load files but also failed.

[UnaNancyOwen]

The x86 tests seems to have failed, but the tests is running correctly. 👍

[taketwo]

Just a single failing test on x86 build (due to precision), x64 finished with success. I wonder if we actually need x86 build at all. Does anyone use it anyway? Would it make more sense to rather have an additional VC2015-based x64 build?

In the meantime I've pushed a commit with vtk to check how much longer it will take.

By the way, Azure supports "release" builds that produce artifacts. @UnaNancyOwen do you think it makes sense to try to setup a pipeline that produces all-in-one installer automatically? I don't know how hard this would be, but can imagine it will reduce friction on releases even further.

[UnaNancyOwen]

I wonder if we actually need x86 build at all. Does anyone use it anyway? Would it make more sense to rather have an additional VC2015-based x64 build?

(I think it is unnecessary, but) it seems that there is still demand because questions about that comes me still.
Fortunately, the Azure Pipelines processes jobs in parallel. It may be good to add job for VC2015.
(It is 10 parallels by default. Probably, We can increase number of parallels by asking MS.)

@UnaNancyOwen do you think it makes sense to try to setup a pipeline that produces all-in-one installer automatically?

I think it is difficult. It requires some manual work (in my procedure).

[taketwo]

I think we have to live without vtk for now. It took 1 hour to install dependencies with it, and the library failed to build because the agent ran out of space.

Regarding the x86 build, ok, let's keep it. We need to change the expected value in the SHOT test then. At the moment:

test_shot_estimation.cpp(698): error:
The difference between shots352->points[103].descriptor[20] and 0.17439659
  is 0.00020363987049101806, which exceeds 1e-4, where
shots352->points[103].descriptor[20] evaluates to 0.17419295012950897

On my Ubuntu machine I get 0.17442291975021362 currently, so there is no way to choose a new expected value keeping the same tolerance. Also, interestingly, it is only the OMP version that fails the test. Exactly same check succeeds with non-OMP version.

[SergioRAgostinho]

I have the impression this particular test failure has occurred non deterministically in the past.

If only the OMP version is failing we can first try to replicate the strategy we applied here 2bf4ae0 to ensure a single unified test in both classes. If only OMP fails then at least we're sure it's really the differences introduced in the OMP variant.

[UnaNancyOwen]

I think we have to live without vtk for now. It took 1 hour to install dependencies with it, and the library failed to build because the agent ran out of space.

Hmmm, It seems to be 10GB/agent. (Microsoft-hosted agents for Microsoft Pipelines | Microsoft Docs)
@kaylangan Could you give us additional storage space of agent?

[SergioRAgostinho]

As a workaround, we can also erase the build folder vcpkg uses halfway through the process. They're known to generate a lot of "compilation clutter". For more info see microsoft/vcpkg#248

[taketwo]

Could it be an option to install VTK from official package? These additional 40 minutes of compilation to the pipeline execution make me feel uneasy.

[SergioRAgostinho]

I think the best compromise we have is to use windows containers with the dependencies already set up, like you did for Ubuntu. For what I understand Azure Pipelines supports it.

Till then I'm also against vtk on the windows CI.

[taketwo]

I did not realize there are containers with Windows inside nowadays! But from what I see they can not be created from a Linux host and I currently don't have access to Windows. Maybe at some later point. Or perhaps some other Windows user could create an image.

After merging #2636 both jobs succeeded, so either there was a discrepancy in the OMP and non-OMP tests, or it is a spurious failure and will show up later. Either way, I think this is good to go. I suppose we can drop Appveyor config now.

[SergioRAgostinho]

@PointCloudLibrary/maintainers I've disabled all webhooks for AppVeyor. If no one opposes I would actually delete all the unused webhooks. I believe we need @jspricke or @rbrusu to remove Travis from our GitHub apps.

[kaylangan]

It is mean there is no cache feature in Azure Pipelines?
@kaylangan She may know good ideas and information.

We currently do not have a caching feature. We're in the process of designing it. You can see initial plans here.

[kaylangan]

@kaylangan Could you give us additional storage space of agent?

Unfortunately, we cannot increase the storage space of agents since we're constrained by the specs of the VMs we use in our pools. We're planning on building a "bring your own server" feature where projects can bring their own, custom hardware, but I don't have an ETA for that.

[taketwo]

@kaylangan Thanks for sharing this information. Looking forward for the caching feature to be implemented!