Here’s the thread pull:
- Faulty job. Pull Request #44 #164.8 failed, June 22, 2020 11:53:29, rustc 1.46.0-nightly (4fb54ed48 2020-06-14), cache ID
PR.44/cache--linux-xenial-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--cargo-nightly– takes it from PR - 1st build in this PR. Pull Request #44 #162.8 failed, June 22, 2020 11:11:51, rustc 1.46.0-nightly (4fb54ed48 2020-06-14), cache ID
master/cache--linux-xenial-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--cargo-nightly.tgz– takes it frommaster - Last
masterbuild before that. master Merge pull request #43 from RalfJung/raw_ref, #161.8 passed , June 20, 2020 16:40:24, rustc 1.46.0-nightly (2d8bd9b74 2020-06-19), no cache, saves cache IDmaster/cache--linux-xenial-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--cargo-nightly - So cache poisoning happens somewhere between 161.8 and 162.8. Let’s take a closer look at build 161, especially at Miri’s handiwork.
- Miri job from 161. master Merge pull request #43 from RalfJung/raw_ref, #161.1 failed , sets default to
nightly-2020-06-15-x86_64-unknown-linux-gnu… saves cache IDmaster/cache--linux-xenial-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855--cargo-nightly
So jobs 161.1 and 161.8 use the same cache ID!
That’s because their configuration only differs in job name and script. Cache ID is computed from OS image, language version and environment variables as specified in .yml (see What is the cache ID for a job generated from? How can staged jobs use the same cache? for source code links). Job name and script are not considered!
It looks like whoever was using MIRI= envvar in Travis CI - Test and Deploy with Confidence (huh, that was actually you) was doing that for a reason! But they forgot to leave a comment in yml explaining their decision, letting that knowledge become lost!