Vcpkg: CI is undocumented

[cenit]

While appreciating public CI, I have some problems related to the fact that it is a little bit undocumented.
I think we can understand how it works, storing blobs and not rebuilding them if not necessary (no mods in the port itself, no mod in any dependency), but for example I can't understand your reasons to add/remove packages from exclude.
At the moment this is the value:
--exclude=vxl,gherkin-c,tmx,ms-angle,ecm,llvm,catch-classic,libpng-apng,libmariadb,libp7-baical,luajit,mozjpeg,theia,shogun,winpcap,range-v3-vs2015,ogdf,libressl

May I ask you why? Isn't it better to remove it? How to opt-out from them? For example, I spent a lot of time fixing theia and shogun, but now I can't understand why they are on that list.
I had some problems merging from master with latest Homepage addition to CONTROL: regressions exploded (I had only a couple which were easy to fix, and only on osx) and I am just wandering what happened in the meantime...
also because that PR is full of work, which is getting old and duplicated with time passing... (edit: of course I know that it is difficult to merge a PR like that, but as @vicroms knows, it is also difficult to disentangle mods at the beginning, only when work is finished I am able to do that)

[Rastaban]

I have been slowly working on the documentation for the CI system, I can bump it up in priority though.

[cenit]

Thanks. Just a comment on the exclude parameter opt-out (if possible at all) would be useful.

[Rastaban]

Most of the ports on the exclude list are there because they are either flaky or have conflicts with other ports. There are exceptions like llvm which was put onto the list because it takes a long time to build. I want to shrink that list (or get rid of it) so I plan on making changes to the CI system which will allow the conflicting ports to be installed in isolation.

[Rastaban]

The documentation is slowly coming together: https://github.com/Rastaban/vcpkg/blob/test_docs/docs/maintainers/automated-testing.md

[BillyONeal]

I'm closing this because all our CI infrastructure is now available in the repo under $/scripts/azure-pipelines.