Add Ubuntu16.04 based build on Azure Pipelines

[taketwo]

This PR adds a new job that builds PCL in the Ubuntu 16.04 based image. It also switches the documentation job to use a dedicated "doc" image with Doxygen and other necessary tools.

I've created a new organization on Docker Hub to host "environment" images where all PCL dependencies are pre-installed. The images from this organization will be used for containerized builds on Azure Pipelines. For the time being I created these images locally and pushed to the registry. In future we may commit their respective Dockerfiles to the main PCL repository (or a supplementary one) and setup a separate pipeline to rebuild and push them to the registry automatically.

[SergioRAgostinho]

Edit: wrong thread sorry for the spam. I'll add it to the original.

@taketwo Read this https://docs.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=vsts&tabs=yaml#timeouts

You need to set the timeout explicitly to 0. A maximum limit still exists and it is 6 hours.

Edit 2: Don't forget about the status badge. https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started-yaml?view=vsts#get-the-status-badge

[taketwo]

Thanks for the tip! With timeout set to zero the job succeeded (on my private account, log here). It took 3 hours to build the library though, really long. That was without passing -j option to make, so I've also tried to set -j2 and -j3. This leads to faster build progress, however inevitably ends up in a failure at some late stage of the build. I restarted the pipeline multiple times, but it always eventually failed. Here is an example of such failure. Unfortunately, Azure is not informative about the problem and refuses to provide a complete log of the step up until the failure, so we can not check at which exact point during the build it failed. I suspect it's some sort of out of memory error, we had similar a similar problem in the early days on Travis. The hacky solution was to build the memory-heavy targets with a single thread, and the rest of the targets with multiple threads. I'll try to use the same technique here.

[SergioRAgostinho]

Unfortunately, Azure is not informative about the problem and refuses to provide a complete log of the step up until the failure, so we can not check at which exact point during the build it failed.

It doesn't allow me to download to the log of the failed build :/

I suspect it's some sort of out of memory error, we had similar a similar problem in the early days on Travis.

That would also be my intuition. Did you know the "resource limits" of their VMs? In Travis we were not able to compile with -j2 in the container infrastructure and that was a reason to move to their sudo enabled builds. It provided slightly more memory.

The hacky solution was to build the memory-heavy targets with a single thread, and the rest of the targets with multiple threads. I'll try to use the same technique here.

We never really get rid of the highly involved CI pipelines.

[taketwo]

It doesn't allow me to download to the log of the failed build :/

I can download, but it has exactly the same contents as in the web interface, i.e. only "Build Library failed" line.

So the following works and finishes in 1h 44m:

          cmake --build . -- -j2 pcl_filters
          cmake --build . -- test_filters
          cmake --build . -- -j2 pcl_registration
          cmake --build . -- test_registration test_registration_api
          cmake --build . -- -j2

I also tried -j3, but it took 10 minutes longer.

I will add one more commit on top, removing Travis pipeline and replacing the CI badge in the README, and then we are ready to go.

[SergioRAgostinho]

👍 It might be worth to add a minor comment to the config file explaining the need for this "build order".

          cmake --build . -- -j2 pcl_filters
          cmake --build . -- test_filters
          cmake --build . -- -j2 pcl_registration
          cmake --build . -- test_registration test_registration_api
          cmake --build . -- -j2

[taketwo]

Done.

[SergioRAgostinho]

Super. Thanks a lot Sergey.