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

[liby]

Current Behavior

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

    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

    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]

@agilgur5

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

[agilgur5]

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]

@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.

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.