fix: replace tj-actions/changed-file by step-security/changed-files

[JagjeevanAK]

tj-action/changed-files is compromised and I have replaced it with the best alternative of it.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 49.86%. Comparing base (e8deee5) to head (4d8a395).
Report is 13 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #11644      +/-   ##
==========================================
- Coverage   49.88%   49.86%   -0.03%     
==========================================
  Files          83       83              
  Lines       22984    22990       +6     
  Branches     5508     5511       +3     
==========================================
- Hits        11466    11463       -3     
- Misses      10121    10125       +4     
- Partials     1397     1402       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jayaddison]

I think we might be able to use the paths filter that is built-in to GitHub Actions to achieve what changed-files was doing for us. It would be less code, and that could be good: it means less code to review and that could have bugs / problems in future.

The tricky part is that this repository uses GitHub Actions required status checks. However: I think it may be possible to have an inverted workflow that has paths: * where the checks always succeed (exit 0). GitHub will (I think!) still prevent a PR from being merged if a check from the more specific path filter (for example, paths: *.md) fails.

[github-throwaway]

Context:

https://www.stepsecurity.io/blog/harden-runner-detection-tj-actions-changed-files-action-is-compromised

[JagjeevanAK]

Malte he knew it that was compromised and he was the first-one who updated me.

[jayaddison]

@JagjeevanAK do you think we could implement the required functionality without changed-files? I guess we want to handle multiple cases: changed documentation, changed Docker files, ... maybe other filetypes too?

That would be more complicated than what I've tested so far, so I'm not sure.

[JagjeevanAK]

I believe you are not seeing the broader picture yet. While we can certainly test just for docs, but our main goal is to avoid rebuilding the Docker container each time. To achieve this, we need to monitor which files have been modified. I've been experimenting with this on another branch/ different pull request.

[jayaddison]

Understood. Would the GitHub Actions paths filter be usable to detect those docker-related changes, or are there reasons that that would not meet the requirements?

[alexgarel]

@jayaddison path filter is only to decide whether to run or not the action, not to be able to decide which step to run. Also we need to do boolean operations with changed files, which is not possible with path.

[alexgarel]

Thanks.

[jayaddison]

@jayaddison path filter is only to decide whether to run or not the action, not to be able to decide which step to run. Also we need to do boolean operations with changed files, which is not possible with path.

Thanks @alexgarel. I had considered relocating individual jobs into separate workflow files to achieve some of the choice diagram aspect -- but that would not work for individual steps within jobs -- so OK, this makes sense.

The boolean conditions part remains less clear to me, so I'll keep thinking about that. However, I certainly recognize that there are more advanced use-cases and conditions that could be solved by using scripts.

[jayaddison]

@JagjeevanAK If/when you have time, could you let me know the reasons/bugs that made dorny/paths-filter no longer suitable?

I know my questions probably seem very repetitive; I'm trying to understand why it made sense to make the change, mainly because I think we got lucky avoiding the compromise, and also because to me, paths-filter seems to have fewer and smaller dependencies (so, if I were choosing between two otherwise similar components, I would probably choose the smaller/simpler one).

[JagjeevanAK]

Hey @jayaddison, there is nothing called repetitive —we are all learning day by day. The reason behind shifting from dorny/paths-filter was that it was not working as it was supposed to or as described in the docs. There were some errors and inconsistencies. Though it was lightweight and faster than tj-action/changed-files, I thought it was a good time to move on to the second-best option.

[github-throwaway]

@jayaddison the beauty of open source is you can always try for yourself. If you want to test a different implementation yourself, go for it. That's the best way to learn ☺️

[jayaddison]

Thanks @JagjeevanAK @github-throwaway. I'd like to test it, and am willing to; I'm not sure what behaviour(s) to check for, though (I have begun searching through the paths-filter issue tracker to try to guess at things that might not work as documented).

[jayaddison]

Thanks @JagjeevanAK @github-throwaway. I'd like to test it, and am willing to; I'm not sure what behaviour(s) to check for, though (I have begun searching through the paths-filter issue tracker to try to guess at things that might not work as documented).

I'll add any additional relevant notes in #11630, because that seems to be the more relevant location. I have one or two ideas to examine and test.