Caching ${TRAVIS_HOME}/.cargo does not work with bash branch of basher

Environments Windows
,
1

The ${TRAVIS_HOME}/.cargo directory is used by Rust’s cargo to store executables installed through cargo install. However, the cached directory does not contain the installed executables on the next run on Windows.

I verified that the correct cache file is restored:

  • job 1: installs the executables, verifeis that they’re available in ${TRAVIS_HOME}/.cargo/bin, and caches that directory in a file named PR.535/cache-windows-1803-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--cargo-nightly.tgz
  • job 2: restores PR.535/cache-windows-1803-containers-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--cargo-nightly.tgz (the exact same name), but the installed executables are no longer in ${TRAVIS_HOME}/.cargo/bin.

This leads to really long build times since the executables are recompiled in each job.

2

I did some investigation: it seems like the problem is in the bash branch of casher. When I add the branch: bash to my travis config as described here, I see the same behavior on Linux and macOS.

3

Could you point to the build log URL to show the problem?

4

Sure:

  • Job 483091891: On the first ls ${TRAVIS_HOME}/.cargo/bin the executable bootimage.exe is not present. It is then installed and shows up on the second
    ls ${TRAVIS_HOME}/.cargo/bin. At the end of the job, the build cache is updated and the bootimage.exe is listed as new file. (The output is mangled, I don’t know it that’s the problem).
  • Job 483110208: On the subsequent job the cache is restored (same cache file name), but the first ls ${TRAVIS_HOME}/.cargo/bin does not contain bootimage.exe.
    • The Linux and macOS jobs of the same build (default casher) have the bootimage executable present after restoring the cache.

When I change casher to the bash branch (branch: bash), the Linux (and macOS) builds show the same behavior as Windows:

  • Job 483123213: First job after switching to branch: bash.
  • Job 483131073: Subsequent job restoring the cache, but the ${TRAVIS_HOME}/.cargo/bin directory does not contain the bootimage executable.
5

I see. \t in the path inside ${TRAVIS_HOME} is interpreted as a tab, resulting in the wrong path when creating the cache archive.

6

Ah, that explains the strange output. I see that there is an open PR for this at https://github.com/travis-ci/casher/pull/38. Are there any ways to work around that issue until it is merged?

7

It does not try to create paths containing tabs, that is just a display issue (but highly confusing). The problem is lack of support for absolute paths (which is fixed by the PR linked above).

Some more details (and an ugly workaround) are documented at:

Basically it requires you to move the extracted directory (probably named “Users” for C:\Users.…) from the current directory to the right location and recompute the cache checksums to avoid reuploading the same cache at the end of the test run.

Another idea is to cache the .cargo directory in the current working directory and attempt to create a symlink from $TRAVIS_HOME/.cargo as relative paths should be handled just fine. Not sure how well that is supported on Windows though.

@BanzaiMan Please consider merging Bash fixes for extracting absolute paths and corrected message prints by Lekensteyn · Pull Request #38 · travis-ci/casher · GitHub, it would allow some ugly hacks to be removed from the .travis.yml files.

2 Likes