Virtual-environments: Wrong version of vcpkg has been installed

Created on 25 Nov 2020 · 7Comments · Source: actions/virtual-environments

Description
Although the documentation states that 18.04 is using Vcpkg 2020.11.12, this does not appear to be a legit version. The VCPKG repo has tags for 2020.11 and 2020.11-1.

Area for Triage:
Packages

Question, Bug, or Feature?:
bug

Virtual environments affected

[ ] Ubuntu 16.04
[x] Ubuntu 18.04
[ ] Ubuntu 20.04
[ ] macOS 10.15
[ ] macOS 11.0
[ ] Windows Server 2016 R2
[ ] Windows Server 2019

Expected behavior
Installed version of vcpkg should match a released tagged version.

Actual behavior
Currently installed version of vcpkg matches commit 5dc5321 which was published on Nov 13th. This not a tagged release from the vcpkg repo. It's roughly 11 days after tag 2020.11. I don't believe this interim build should be running on the hosted machines as it has not an official tagged version. This is causing a build break with some packages.

Repro steps
Using vmImage = ubuntu-18.04, the following will fail.

vcpkg install microsoft-signalr

Wait 20+ minutes to build the 68 dependencies and finally when it gets to the signalr package, the install breaks.

I have confirmed locally that vcpkg at the installed commit will fail when attempting to build the signalr library. If the tagged version 2020.11 is used, there is no problem.

Note: in prior builds, the installed version of vcpkg used a specific tag not an interim commit.

C++ awaiting-deployment question

Source

mprather

All 7 comments

Hello @mprather ,

We always install vcpkg from master branch, not from latest release. So we just picked up latest commit on master branch in day when image was generated. See related code: https://github.com/actions/virtual-environments/blob/main/images/linux/scripts/installers/vcpkg.sh#L15

Per communication with vcpkg owners, installation of latest release can bring incompatibility problems since vcpkg releases new versions rarely (latest release was happened at the begin of November, previous release on July). See related discussion in https://github.com/actions/virtual-environments/issues/1332#issuecomment-672757305

maxim-lobanov on 25 Nov 2020

Hi, @mprather ,
I hope that @maxim-lobanov have clarified the vcpkg versioning policy, so I'll close this issue for now, but if you have any suggestions, please feel free to ask.

LeonidLapshin on 25 Nov 2020

I think this stance needs to be reconsidered.

Think about these two questions..

Why in the world would the vcpkg team create tagged releases if all commits were golden all the time?
Should Azure VM default to stable, known release points or use untested, potentially unstable releases?

For the first question, I can tell you that each tagged release since 2020.06 works for all our cases/uses of vcpkg. Daily commits break frequently enough that we have stopped using latest. Today it might work, tomorrow it might not. Why should the Azure Hosted machines take the risk of landing on a build that doesn't work?

For the second question, the mantra should be "We install the latest release. If you want something newer or different, then it's your option to go cutting edge." It should not be the opposite -- "We'll install some bits that may or may not work. You'll have to burn your time to find out. If you want stable, install it yourself."

The hosted vms should use known release points, not the latest commit on any given day. This effectively means rather than having a trusted configuration and being able to rely on the bits this team has installed on the vm, my team must now update _all_ of our build definitions to install VCPKG, set the checkout to proper release point, build vcpkg, then install. This increases our dev/maintenance costs and, worse, burns valuable pipeline time. This will be the only way to ensure we won't run across broken builds of the toolset. I have always assumed that the hosted vms used known release points. Learning this policy doesn't exist is disappointing.

Please reconsider the implications of just installing some random daily commit.

If you decide to not change direction, then I would recommend that you update all documentation to clearly put asterisks or categorize all toolsets that installed with day-of commits. Otherwise, it could be highly misleading to say that you installed a "release". For example, the documentation states "vcpkg 2020.11.12" was installed. I didn't catch the ".12" in the label until all our builds failed. Using a faux release name that is too similar to the actual release tag name is not a good thing. How about "vcpkg commit 5dc5321"? This would clearly state what was done and avoid any confusion.

mprather on 25 Nov 2020

👍1

@mprather ,
That problem discussed in https://github.com/actions/virtual-environments/pull/1340 was about vcpkg / cmake incompatibility and it looks like it affected a lot of customers.

Shortly: On VM images, we always install the latest version of cmake. Vcpkg depends on cmake and any new cmake version can be potentially incompatible with vcpkg. In this case, vcpkg team has to fix it.
If we pick up the latest commit from vcpkg repo, we can be sure that it is compatible with new cmake. If we pick up the latest release, most likely it is pretty outdated (in comparison with master branch) and very likely doesn't support current cmake and vcpkg can be broken. More details in https://github.com/actions/virtual-environments/pull/1340#issuecomment-667543372

Just to clarify, personally, we are not vcpkg experts and can't prove what approach is better - installing the latest commit or latest release.
Decision to use approach with latest commit was taken based on the customers' feedback on issue above.

Also, as I can see in official vcpkg documentation, the recommended way to install vcpkg is using latest commit from master branch:

We don't have concerns to re-discuss this decision in our repo or in vcpkg repository.
If we would get recommendation from vcpkg team to use different approach, we would be happy to revisit it. But we need to have clear understanding about possible impact and need to be sure that new decision is better than current one on long term perspective. For now, it looks like using latest commit is recommended approach.

cc: @strega-nil (from vcpkg team), Hello!
Could you please share your opinion on the message above? What installation approach would you recommend for vcpkg tool in CI? Does it make sense to use latest release or latest commit from master branch?

@mprather , I am reopening this issue for now since as you mentioned above, it definitely makes sense to update image documentation to be clear that we install vcpkg from master branch and print exact commit.

maxim-lobanov on 25 Nov 2020

We are hopefully giving a better stabilization story in a month or so, but as of this point either choice is valid. Soon (TM), we hope to release the vcpkg binary once a month, and update the ports tree all the time, basically, and use versioning to support older sets of ports (we really want to untie the vcpkg binary from the set of ports that you want). Hopefully, we'll update you then on the configuration we expect people to use.