Requesting approval for the GitHub Action tj-actions/changed-files

[dbast]

---

Feature request

I formally request approval for the GitHub Action tj-actions/changed-files (used by 21,000+ repositories) to be allowlisted in our repository's workflows. I'm collaborating with @esc and @swap357 to migrate build and test automation from the internal build farm to GitHub Actions. Leveraging established, well-tested community Actions is a crucial pattern in GitHub workflows that significantly improves development efficiency.

Context: Currently, only GitHub-provided Actions (e.g., actions/checkout, actions/cache) are permitted, as third-party Actions are considered potential security risks due to their mutable nature.

Security measures: We'll follow best practices by pinning the Action to its specific SHA1 hash instead of using tags, ensuring immutability. Renovate can automate this process. This approach, widely adopted by security-conscious projects, prevents unauthorized Action modifications and ensures reproducibility. While this could justify allowing all Actions, I'm specifically requesting approval for tj-actions/changed-files.

[esc]

@dbast thank you for asking about this. We will discuss during the developer meeting next Tuesday.

[dbast]

Why is that action useful/needed?: With Github Workflows it is possible to compose huge DAGs. The changed-files action allows then to figure out what files changed as part of an PR and disable that part of the DAG that doesn't need to run and can be skipped.

Example: DAG = build llvmdev (wheel/conda pkg) -> build llvmlite (conda/wheel pkg, different Python versions) -> test llvmlite (... all variants) ... depending on what files changed, parts of that DAG can be skipped:

• if nothing changed in the folder ./conda-recipes/llvmdev then rebuilding llvmdev conda package can be skipped and instead retrieved from e.g. .org
• if nothing changed in the folder ./conda-recipes/llvmdev_for_wheel/ then rebuilding that can be skipped ...
• if specific workflows/action files in .github/... changed then the whole DAG has to run as the DAG changed.
• ...

The changed-files action is kind of a standard building block for bigger Github Workflows.

[dbast]

so some quality checks (to be checked for any OSS dependency, not specific to actions) for https://github.com/tj-actions/changed-files:

• has several active devs https://github.com/tj-actions/changed-files/graphs/contributors
• applies best engineering practices (code testing with coverage, linting…) see https://github.com/tj-actions/changed-files/blob/main/package.json#L11
• runs a single pinable .js file https://github.com/tj-actions/changed-files/blob/main/action.yml#L328 without loading any dependency during execution (thats how js actions are designed)
• the action code in https://github.com/tj-actions/changed-files/tree/main/src looks good (no download of external code)
• is widely used in 21k repos … so issues would get known pretty fast
• has a security policy https://github.com/tj-actions/changed-files/security

Anyways, a Github Action is not more dangerous than wget $URL | bash or npm/conda/pip install $package, which is already possible in PRs. Action workflows as triggered by PRs run in disposable VMs with not secrets access.

[gmarkall]

I'm +1 on allowing this action and I have no concerns - the considerations appear to have been addressed thoroughly and thoughtfully.

[sklam]

The Numba Devs have approved the use of requested github action here in today's meeting. We agreed to setup the checklist in the wiki for future reference to how we review GHA. In addition, we need to have a discussion with @dbast, @esc and @swap357 in one of our Numba meeting so that the rest of us can understand more on the GHA security and supply chain concerns that we have.

@esc, here're some TODOs:

• adjust the org setting to enable the action
• add the wiki page for the action review checklist
• communicate with @dbast and @swap357 get a good meeting date. We can either use the triage or the office-hour/dev-meeting time slot.

Thanks you!