jaredpalmer / tsdx

Zero-config CLI for TypeScript package development
https://tsdx.io
MIT License
11.24k stars 508 forks source link

@actions/cache: After modifying `key`, `Cache not found for input keys: xxx` will not be thrown #928

Closed liby closed 3 years ago

liby commented 3 years ago

Current Behavior

image

I modified key, but when I run the workflow, it still prompts me for Cache restored from key: Linux-jd-node-modules-xxxx.

Expected behavior

Isn’t it supposed to prompt me Cache not found for input keys: Linux-jd-node-modules-?

Suggested solution(s)

After modifying Key, the cache should not be restored from the previous key when the workflow is run for the first time.

Additional context

Before modification ```yml steps: - uses: actions/checkout@v2 - name: Cache node_modules uses: actions/cache@v2 env: cache-name: cache-node-modules with: path: node_modules key: ${{ runner.os }}-${{ env.cache-name }}-${{ hashFiles('package-lock.json') }} ```
After modification ```yml steps: - uses: actions/checkout@v2 - name: Cache node_modules uses: actions/cache@v2 env: cache-name: cache-node-modules with: path: node_modules key: ${{ runner.os }}-${{ env.cache-name }}- ```

Your environment

  System:
    OS: Linux 5.4 Ubuntu 18.04.5 LTS (Bionic Beaver)
    CPU: (2) x64 Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz
    Memory: 4.80 GB / 6.79 GB
    Container: Yes
    Shell: 4.4.*** - /bin/bash
  Binaries:
    Node: 10.23.0 - /opt/hostedtoolcache/node/10.23.0/x64/bin/node
    Yarn: 1.22.5 - /usr/bin/yarn
    npm: 6.14.8 - /opt/hostedtoolcache/node/10.23.0/x64/bin/npm
  Browsers:
    Chrome: 86.0.42***.183
    Firefox: 82.0
liby commented 3 years ago

@agilgur5

I'm sorry, I was so careless. I must have mistaken the code repository in a hurry. Sorry~

agilgur5 commented 3 years ago

Sorry, your question is with regards to @actions/cache, which is a different library that TSDX has no control over. Based on your output environment, it doesn't look like you're actually using TSDX, and based on your screenshots, it doesn't look like you're using the TSDX GitHub Actions template either. Maybe you've filed the issue in the wrong repository.

If you were using the TSDX GitHub Actions template, it would also be out-of-date, since the TSDX templates no longer use @actions/cache directly since #882.

Again, this is not related to TSDX, but I can see a potential issue here:

          key: ${{ runner.os }}-${{ env.cache-name }}-

restore-keys can have a partial match, so that could still be a cache hit. Though I believe key is supposed to be exact match only.

liby commented 3 years ago

@agilgur5 I apologize again for my carelessness.

I looked at the history, and I think I entered here through #799 when using Google search, and because the situation is similar, I subconsciously think that this is the cache code repository. image

Again, this is not related to TSDX, but I can see a potential issue here:

Thanks for your kindness!

restore-keys can have a partial match, so that could still be a cache hit. Though I believe key is supposed to be exact match only.

According to the log, this is very similar to the behavior after the restore-keys has been set. But what is confusing is that I do not configure restore-keys.