Conflicting cache name using CircleCI

[sbr-dev]

Describe the bug
When using CircleCI + caching vcpkg dependencies, the cache key : my-cache already exists in vcpkg directory and results in a error :

Found a cache from build 69 at my-cache
Size: 1.9 MB
Cached paths:
  * /root/project/libs/vcpkg

Downloading cache archive...
Validating cache...

Unarchiving cache...

Failed to unarchive cache

Error untarring cache: Error extracting tarball /tmp/cache933926973 : tar: root/project/libs/vcpkg: Cannot mkdir: Permission denied tar: root/project/libs/vcpkg/.gitattributes: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github: Cannot mkdir: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE: Cannot mkdir: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/i-have-a-question.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/other-type-of-bug-report.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/report-package-build-failure.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/request-a-feature-or-improvement-to-a-port.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/request-a-feature-or-improvement.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/request-a-new-port.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE: exit status 2

Changing the cache name to something else solved the issue

This post is primarily indented to people who might struggle with CircleCI caching & vcpkg because of the wrong key.

All the best

[heydojo]

If you are not modifying your build chain and environment all the time and you are caching to create an environment which produces reproducible builds, then you should only need to cache:

• vcpkg\installed
• vcpkg\packages

instead of the entire vcpkg directory.

[sbr-dev]

Possible workaround indeed, but I haven't checked if caching these two with the cache key my-cache works on CircleCI

[heydojo]

I'm not familiar with CircleCI but actually:

Error untarring cache: Error extracting tarball /tmp/cache933926973 : tar: root/project/libs/vcpkg: Cannot mkdir: Permission denied tar: root/project/libs/vcpkg/.gitattributes: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github: Cannot mkdir: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE: Cannot mkdir: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/i-have-a-question.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/other-type-of-bug-report.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/report-package-build-failure.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/request-a-feature-or-improvement-to-a-port.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/request-a-feature-or-improvement.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE_TEMPLATE/request-a-new-port.md: Cannot open: Permission denied tar: root/project/libs/vcpkg/.github/ISSUE: exit status 2

Is a permissions error on a Linux server, so you likely need to be building in a directory that the build bot has write access to. But like I said, I am unfamiliar. It's just my initial observation.

https://circleci.com/docs/2.0/caching/#basic-example-of-dependency-caching

EDIT: I looked and it looks like you are attempting to use the example key my-cache. The documentation here: https://circleci.com/docs/2.0/configuration-reference/#save_cache
says that you could use something like:

• myapp-{{ checksum "package-lock.json" }}
  or
• myapp-{{ .Branch }}-{{ checksum "package-lock.json" }}
  or
• myapp-{{ epoch }}

instead of my-cache. Please see the documentation for why. Each different syntax produces different results.

Also, you are trying to restore cache into the special folder /root. On systems such as Debian - the /root folder is the user account folder for the root user. It's unlikely that the build bot has permissions to write to that folder as it shouldn't be running as root.
So; you should create your builds inside a different brand new folder which you have manually created using the mkdir command. Some examples are /mybuild or /build or I like to use /opt/build.
Once you have created the folder using mkdir, then chmod the folder if possible, setting full read/write/executable access to anyone before you build inside it. It may also help to chmod the folders you will cache once the build has finished too.

[sbr-dev]

As I said before, it's stricly linked to the cache name itself. Actually we're using a cachename with a checksum appended to identify it and periodiccaly redownload everything from scratch. In this situation, it's working perfectly. Switching back to my-cache triggers the error.

Maybe this is an issue more related to CircleCI but i don't think it is since we tried it on another platform / project and it worked.

The "right" issue you mentionned comes from the checkout command of CircleCI. It's a limitation of CircleCI itslef. If you don't change the default working directory, checking out in an non-empty directory is a bad idea : https://discuss.circleci.com/t/directory-tmp-you-are-trying-to-checkout-to-is-not-empty-and-not-git-repository/11370

Anyway, we easily pass through this issue by simply changing the cache name. It's a post just intended for those who might get the same issue and try to find a solution

All the best

[heydojo]

Maybe this is an issue more related to CircleCI

My observations too.

tar: root/project/libs/vcpkg: Cannot mkdir: Permission denied

And like I said, root is a special user folder for the top level account in quite a few Linux distributions, so better not to build there and then attempt to cache the results.
I've not personally experienced any issues loading vcpkg from cache using Appveyor so I'm sure you'll be able to find a workaround. Good luck!

[PhoebeHui]

@aspioupiou, does this still be a problem for you?

[sbr-dev]

@PhoebeHui We've changed our cache name and this solved the issue. As @heydojo suggested, several solutions exists to automatically change it.

However, I expect my libraries to not interfere in my CI pipeline. By using the default circleci cache name, it's easy to reproduce such issue.

Why not changing vcpkg's cache name ? It's a quick and reliable fix in my point of view. Something like vcpkg-ci-cache is detailed enough to avoid overlap with main projets cache name.

[ras0219-msft]

Hi @aspioupiou, how are you using vcpkg with CircleCI? What documentation are you following?

[sbr-dev]

Hi @ras0219-msft, we switched from CircleCI to a self-hosted gitlab instance so this setup is not in production anymore. Globally, we always embed vcpkg inside the project directory as a submodule, meaning each CI build builds vcpkg in the project directory.
If using CircleCI + caching, cache keys overlap