Finding Node 20 Dependencies in GitHub Actions Workflows

In that case, the workflow explicitly inherits the Node version from the repository configuration.

This creates a dependency between the workflow and .nvmrc.

Step 10 - Check Dockerfiles

Node versions are frequently hidden inside container definitions.

For example:

FROM node:20

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
RUN npm run build

This is an application build dependency.

Changing the Node runtime used by GitHub Actions does not automatically mean this Docker image should change.

The correct question is:

Does the application support another Node version?

That needs to be answered independently.

Distinguish Action Runtime From Application Runtime

This is the most important concept in this entire process.

Consider:

steps:
  - uses: actions/checkout@v4

  - uses: actions/setup-node@v4
    with:
      node-version: 20

  - run: npm test

There are two different Node concepts here.

The first is the runtime used internally by actions/checkout.

The second is the Node runtime configured for:

npm test

Changing one does not necessarily change the other.

A useful mental model is:

GitHub Actions infrastructure
          |
          +-- Action runtime
          |
          +-- Runner
          |
          +-- Shell commands
                    |
                    +-- Application runtime

Treat each layer independently.

Example - A .NET Repository

Suppose your repository contains:

src/
tests/
.github/workflows/
Dockerfile

Your workflow is:

name: .NET CI

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.x'

      - run: dotnet restore
      - run: dotnet build --no-restore
      - run: dotnet test --no-build

There is no application-level Node dependency.

However, actions/checkout and actions/setup-dotnet can still use JavaScript internally.

Therefore, a search for:

node-version: 20

will not necessarily reveal every Node-related workflow dependency.

Example - A Node.js Repository

Now consider:

name: Node CI

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - run: npm ci
      - run: npm test

Here Node 20 is explicitly part of the application's CI environment.

If the project moves to another supported Node release, the workflow needs to be updated and tested.

This is separate from any Node runtime used internally by actions/checkout or actions/setup-node.

Search for Node Commands

A workflow can also invoke Node directly.

Search for:

node
npm
npx
yarn
pnpm

For example:

- run: node scripts/generate.js
- run: npm run build

These commands depend on the Node runtime installed in the job.

A workflow may therefore have an implicit Node dependency even without setup-node.

For example:

- run: npm ci

If the runner provides Node, the workflow can use it.

For production CI, however, explicitly defining the required runtime is generally easier to understand and reproduce.

Build a Dependency Inventory

Once you have searched the repository, create a simple inventory.

This prevents unrelated Node references from being mixed together.

Common Mistakes

Searching Only for node-version

This misses Node runtime dependencies inside JavaScript actions.

Updating Every Node 20 Reference

A Node 20 Docker image and a GitHub Action runtime are different dependencies.

Ignoring Third-Party Actions

Internal and third-party actions may contain the most important compatibility issues.

Updating Major Versions Without Testing

Changing:

some-action@v1

to:

some-action@v2

can introduce breaking changes.

Checking Only the Main Workflow

Release, deployment, security, and scheduled workflows may use different actions.

Troubleshooting

The Workflow Uses Node 20 but You Cannot Find setup-node

Search for:

node
npm
npx
uses:

The Node dependency may come from a command or an action.

An Action Reports a Node Runtime Warning

Identify the action that produced the warning.

Then inspect its current version and implementation.

Updating an Action Breaks the Workflow

Check:

• Inputs

• Outputs

• Permissions

• Runner compatibility

• Runtime requirements

• Release notes

Node Application Tests Fail After a Runtime Update

Check the actual runtime:

node --version
npm --version

Then run:

npm ci
npm test

Look for dependency compatibility problems.

Docker Builds Still Use Node 20

Check whether the Node version is defined in:

Dockerfile
docker-compose.yml
container configuration

An Actions runtime migration does not automatically modify container images.

Best Practices

Maintain an Action Inventory

Keep track of the actions used across your repository.

Review Runtime Dependencies Regularly

Do not wait until a workflow starts failing.

Pin Versions Intentionally

Use explicit action versions and update them through normal code review.

Separate Runtime Layers

Document the difference between:

Application Node
Action Node
Docker Node
Local Development Node

Test CI Changes

After updating an action or application runtime, verify:

Build
Unit tests
Integration tests
Packaging
Deployment

Remove Obsolete Configuration

Once a migration is complete, remove unused Node versions and old workflow settings.

Advantages of a Proper Dependency Inventory

1. Makes migrations easier - You know exactly where Node is being used.

2. Reduces unexpected CI failures - Hidden dependencies become visible.

3. Improves maintenance - Action and application dependencies can be updated independently.

4. Makes troubleshooting faster - Runtime problems can be isolated by layer.

5. Improves documentation - New developers can understand the CI environment more quickly.

Disadvantages and Limitations

1. Repositories can contain many runtime references.

2. Third-party actions may hide implementation details.

3. A text search cannot always determine the actual runtime dependency.

4. Different workflows can use different versions.

5. Action behavior can change between releases.

Practical Node 20 Audit Checklist

Use this checklist before making a runtime migration:

[ ] Search every .github/workflows file
[ ] Find every uses: action
[ ] Search for setup-node
[ ] Search for node-version
[ ] Search for node20
[ ] Search for npm, npx, yarn, and pnpm
[ ] Check third-party JavaScript actions
[ ] Inspect action.yml when necessary
[ ] Check package.json
[ ] Check .nvmrc
[ ] Check Dockerfiles
[ ] Check development container configuration
[ ] Check build scripts
[ ] Separate application runtime from action runtime
[ ] Review action release notes
[ ] Test the complete workflow

Conclusion

Finding Node 20 dependencies in GitHub Actions is more involved than searching for node-version: 20.

Node.js can appear in several layers of a repository. It can be the runtime for application commands, a container runtime, a local development requirement, or the runtime used internally by a JavaScript GitHub Action.

The most important step is to classify each dependency before changing it.

Start by auditing every workflow, inventorying all uses: actions, searching for explicit Node configuration, checking third-party action implementations, and then reviewing application and container configuration separately.

Once the dependencies are mapped, runtime migrations become much more controlled. Instead of changing every Node 20 reference and hoping CI continues to work, you can update each dependency according to what it actually does and verify the result with targeted tests.