[amkkoussay]

Why:

Closes: #46499

What's being changed (if available, include any code snippets, screenshots, or gifs):

One paragraph in dependency-caching.md. The article said GitHub "evaluates the expression hash "package-lock.json"" and showed the final key as npm-d5ea0750. There is no hash function, and per the expressions reference in this repo, hashFiles returns a full SHA-256 hash. The sentence now names the actual hashFiles('package-lock.json') expression, states that the key ends with the complete 64-character hash, and notes the example below shows a shortened version. The same shortened hash is reused later in the restore-keys examples — happy to add the same clarification there if you prefer.

Check off the following:

• A subject matter expert (SME) has reviewed the technical accuracy of the content in this PR. In most cases, the author can be the SME. Open source contributions may require an SME review from GitHub staff.
• The changes in this PR meet the docs fundamentals that are required for all content.
• All CI checks are passing and the changes look good in the review environment.

[github-actions]

How to review these changes 👓

Thank you for your contribution. To review these changes, choose one of the following options:

• Spin up a codespace
• Set up a local development environment

A Hubber will need to deploy your changes internally to review.

Table of review links

Note: Please update the URL for your staging server or codespace.

The table shows the files in the content directory that were changed in this pull request. This helps you review your changes on a staging server. Changes to the data directory are not included in this table.

Source	Review	Production	What Changed
actions/reference/workflows-and-actions/dependency-caching.md	fpt ghec ghes@ 3.22 3.21 3.20 3.19	fpt ghec ghes@ 3.22 3.21 3.20 3.19

Key: fpt: Free, Pro, Team; ghec: GitHub Enterprise Cloud; ghes: GitHub Enterprise Server

🤖 This comment is automatically generated.

[Copilot]

🟡 Changes recommended

The caching documentation makes an unconditional 64-character hash claim despite hashFiles returning an empty string when no files match and does not explain the shortened hash reused in later restore-key examples.

1 open issue

• Qualify empty hash behavior and explain shortened restore-key hashes · New

What changed in this PR

This pull request corrects the hashFiles description and cache-key example in the dependency-caching reference.

Changes:

• Replaces the incorrect hash expression with hashFiles('package-lock.json').
• Documents the full 64-character SHA-256 hash returned for matching files.
• Clarifies that the example uses a shortened hash.

File	Description
content/​actions/​reference/​workflows-and-actions/​dependency-caching.md	Corrects the hashFiles explanation and cache-key example.

_{Review effort: Lite}

[github-actions]

Please don't raise pull requests against an existing issue that another user has raised until it's been marked with a help wanted label. We need to properly assess all issues before we can accept community contributions, and determine whether it's something we need to fix internally, or how many articles are affected and what the scope of the fix will be. For now, we're going to close this pull request.