Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
liby opened this issue Nov 7, 2020 · 3 comments
Labels
scope: templates Related to an init template, not necessarily to core (but could influence core) scope: upstream Issue in upstream dependency solution: out-of-scope This is out of scope for this project solution: outdated This is not up-to-date with the current version

Comments

@liby
Copy link

liby commented Nov 7, 2020

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
    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
@agilgur5 agilgur5 added the solution: out-of-scope This is out of scope for this project label Nov 7, 2020
@agilgur5 agilgur5 changed the title After modifying key, Cache not found for input keys: xxx will not be thrown @actions/cache: After modifying key, Cache not found for input keys: xxx will not be thrown Nov 7, 2020
@agilgur5 agilgur5 added the solution: outdated This is not up-to-date with the current version label Nov 7, 2020
@liby
Copy link
Author

liby commented Nov 7, 2020

@agilgur5

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

@liby liby closed this as completed Nov 7, 2020
@agilgur5
Copy link
Collaborator

agilgur5 commented Nov 7, 2020

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
Copy link
Author

liby commented Nov 7, 2020

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

@agilgur5 agilgur5 added scope: templates Related to an init template, not necessarily to core (but could influence core) scope: upstream Issue in upstream dependency labels Nov 7, 2020
Repository owner locked as off-topic and limited conversation to collaborators Nov 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
scope: templates Related to an init template, not necessarily to core (but could influence core) scope: upstream Issue in upstream dependency solution: out-of-scope This is out of scope for this project solution: outdated This is not up-to-date with the current version
Projects
None yet
Development

No branches or pull requests

2 participants