Add tj-actions/changed-files

[blaginin]

Request for adding a new GitHub Action to the allow list

Overview

I want to add this action, because for Datafusion we need a way to check if the PR has touched some files, and Merge Queue doesn't work with paths-ignore

Name of action: tj-actions/changed-files

URL of action: https://github.com/tj-actions/changed-files

Version to pin to (hash only): 24d32ff

Permissions

Action can work with read only access

Related Actions

There's a similar one https://github.com/Ana06/get-changed-files already in the list, but I believe it's not maintained

Checklist

You should be able to check most of these boxes for an action to be considered for review.
Please check all boxes that currently apply:

• The action is listed in the GitHub Actions Marketplace: https://github.com/marketplace/actions/changed-files
• The action is not already on the list of approved actions
• The action has a sufficient number of contributors or has contributors within the ASF community
• The action has a clearly defined license: MIT
• The action is actively developed or maintained: commits every months since 2021
• The action has CI/unit tests configured: https://github.com/tj-actions/changed-files/tree/main/test

[madrob]

This is the one that had the big supply chain incident, right? https://www.cve.org/CVERecord?id=CVE-2025-30066

[blaginin]

Yes! I pinned a patched version though.

I was also wondering if this should be a reason not to use it - but to me, it feels like a good sign of community engagement and repo maintenance

[raboof]

Indeed using pinned versions is part of what protects us against such attacks.

From https://semgrep.dev/blog/2025/popular-github-action-tj-actionschanged-files-is-compromised/ I understand this was not the first time this repo was compromised. Perhaps you could say that now that they've experienced this compromise they'll be extra careful not to let it happen again in the future - tj-actions/changed-files#2464 possibly suggests so.

[snazy]

If you just need the list of changed files, a simple git diff HEAD^1 should do it. Assuming that you're "just" checking out the PR without explicitly setting the PR HEAD, HEAD points to the PR merge commit. It's first parent is a commit on the PR target branch.
So, this should "just work" and yield the list of files changed by the PR:

git --no-pager diff --name-only HEAD^1

# or put it in a bash array
IFS=$'\n' files_array=($(git --no-pager diff --name-only HEAD^1))

There is also a GH API call, but I'd not use that in a GH workflow, because It yields the list of changed files of the current state of the PR, not at the state of the PR against which a workflow run started (potential race when the PR has changed in the meantime or re-running an older workflow run).

gh pr view "${{ github.event.pull_request.number }}" --json files --jq '.files.[].path'

[blaginin]

I can do that in bash - true! But I don't think it's that simple: for example besides the PR changes you mentioned, I also need to check changed files for pushes, and then handle the exclusions. The code ends up being more complicated than running the tests themselves 😅 Not sure if it's very committer-friendly or easy to follow?

[blaginin]

By the way, I've also noticed we have dorny/paths-filter available but I can't use it either due to dorny/paths-filter#279

[snazy]

I'm just curious how things work ;)
I think, the double-for-loop can be replaced with this, which checks tests all changed files against a list of glob expressions.

shopt extglob
if [[ ${changed_files[@]} == @(*.md|docs/*|.github/ISSUE_TEMPLATE/*|.github/pull_request_template.md) ]]; then
  echo yes
else
  echo no
fi

But yea, without an action, it's bash-magic.

[blaginin]

yes, sure! would you be ok with merging this pr or do you want me to use bash? i d prefer PR but dont mind writing bash hehe 😊

[snazy]

I can't (not an infra guy) :)

[raboof]

if you're comfortable vouching for this action then an approval is welcome even if you're no committer on this repo

[snazy]

I gave it a try.
I'm not a typescript guru, but I couldn't find anything in the action's code base that looks suspicious - like "interesting" exec or GH API calls or the like.
The workflows they have look good to me, nothing obvious that looks like a way to inject malicious code into the build or the like. But I haven't looked into the actions they depend on.
Tests look reasonable, with a reasonable test (case) coverage.
The project itself has quite a variety of contributors and seems overall quite mature.
TL;DR haven't found any "red flags"

[blaginin]

@raboof is there anything else you'd like me to do in this PR? 🙂

[jayaddison]

@raboof

From https://semgrep.dev/blog/2025/popular-github-action-tj-actionschanged-files-is-compromised/ I understand this was not the first time this repo was compromised. Perhaps you could say that now that they've experienced this compromise they'll be extra careful not to let it happen again in the future - tj-actions/changed-files#2464 possibly suggests so.

This might not be relevant to the use case here, but please note that one of the stated remediation actions for PAT tokens for the tj-actions organisation is pending; re: tj-actions/eslint-changed-files#2387

@blaginin

By the way, I've also noticed we have dorny/paths-filter available but I can't use it either due to dorny/paths-filter#279

I think that PR resolves an issue where use of the predicate-actions input parameter emits a warning, because the parameter is absent from the markup defining the inputs for the latest version of the action -- however, in practice, the functionality of the action is unaffected and the parameter can be used.

In other words: a false-positive warning is emitted when using the parameter. Even so, yes, it would be nice to resolve that warning.

[blaginin]

In other words: a false-positive warning is emitted when using the parameter

hmm i m pretty sure it doesn't work without the input properly added: apache/datafusion-sandbox@d04372a#diff-73e17259d77e5fbef83b2bdbbe4dc40a912f807472287f7f45b77e0cbf78792dR58

[jayaddison]

In other words: a false-positive warning is emitted when using the parameter

hmm i m pretty sure it doesn't work without the input properly added: apache/datafusion-sandbox@d04372a#diff-73e17259d77e5fbef83b2bdbbe4dc40a912f807472287f7f45b77e0cbf78792dR58

Ok; my experience was that it worked correctly for a use case to skip GitHub Actions checks on commits that only modify documentation: openculinary/openfoodfacts-server#6

(that was following some of the example documentation from the action itself)

[madrob]

What about on: pull_request: paths: native to github?

[jayaddison]

What about on: pull_request: paths: native to github?

@madrob that feature is certainly useful and can handle many use cases, but, to the best of my knowledge, the smallest GitHub Actions unit it can be used to trigger-or-skip is an entire job -- meanwhile, dorny/paths-filter and the tj-actions/changed-files actions can allow individual steps within a GHA job to be skipped.

(in the OpenFoodFacts PR linked, that was one of the constraints for the use-case)

[jayaddison]

NB also: there is a possible implementation pattern to copy for use of dorny/paths-filter in merge queues at: dorny/paths-filter#183

[blaginin]

What about on: pull_request: paths: native to github?

Path filtering doesn't work with merge queues: https://github.com/orgs/community/discussions/45899

[blaginin]

Ok; my experience was that it worked correctly for a use case to skip GitHub Actions checks on commits that only modify documentation: openculinary/openfoodfacts-server#6

Yeah, that's a fair point. But even in that repo you've referenced, the team switched to changed-files because

dorny/path-filter action, which turned out to be buggy

openfoodfacts/openfoodfacts-server#11630

[jayaddison]

Ok; my experience was that it worked correctly for a use case to skip GitHub Actions checks on commits that only modify documentation: openculinary/openfoodfacts-server#6

Yeah, that's a fair point. But even in that repo you've referenced, the team switched to changed-files because

dorny/path-filter action, which turned out to be buggy

openfoodfacts/openfoodfacts-server#11630

It seemed buggy - but I believe that that was because we were using an old version of it at the time.

My understanding, in more detail:

Initially we tried to enable a predicate-quantifier option when using dorny/paths-filter, in order to adjust the way that the glob patterns are applied (essentially: to use all-patterns-match behaviour instead of the default any-patterns-match to identify changed files) -- we tried that, and confusingly it still didn't work -- so we migrated to changed-files.

However, further investigation noticed that we had been using a v2-edition version of dorny/paths-filter at the time we attempted to enable the option.

Upgrading to the v3.0.2 edition allowed it to work, because that version includes the predicate-quantifier feature, as added by: dorny/paths-filter#224