Refactor verify-action-build into modular package with tests

[potiuk]

Summary

• Split the 3068-line monolithic utils/verify-action-build.py into 15 focused modules organized by responsibility
• Extracted the inline Dockerfile template to a standalone dockerfiles/build_action.Dockerfile file
• Added 112 unit tests across 12 test files covering all modules
• Updated entry points in both pyproject.toml files

Module structure

Module	Responsibility
console.py	Console setup, UserQuit, ask_confirm, link, run
github_client.py	GitHubClient class (gh CLI + REST API)
action_ref.py	Parsing org/repo@hash, extracting uses: refs, detecting action type
approved_actions.py	actions.yml database interaction
docker_build.py	Docker image building + artifact extraction
diff_display.py	Colored diff rendering with pagination
diff_js.py	JS beautification + compiled JS comparison
diff_node_modules.py	Vendored node_modules comparison
diff_source.py	Source file diffing between versions
security.py	All analyze_* security check functions
pr_extraction.py	Extracting action refs from PR diffs
dependabot.py	Dependabot PR review/merge workflow
verification.py	Orchestration + summary display
cli.py	Argument parsing + main() entry point

Test plan

• All 112 new unit tests pass (uv run pytest utils/tests/ -v)
• All 49 existing project tests still pass (uv run pytest -v — 161 total)
• CI pytest workflow passes
• Manual smoke test: uv run verify-action-build <action_ref>

🤖 Generated with Claude Code

[potiuk]

Hey @raboof -> since the tool has gone through a series of iterations and seems to be getting closer to regular maintenance - as asked in the #652 (comment), this one should make it far easier to review further changes.

[potiuk]

I'd really love to merge that one - to be able to extend it's functionality further - I do not want to add more to the monolithical code that is now split, so I'd really love to get it merged,.

[potiuk]

It's generally - pretty safe refactor splitting the code into modules + adding plenty of tests to cover each module - this also will help us to make changes more safely - with test harness keeping the existing functionality.

[raboof]

I'm no Python expert but this looks more managable to me.

It is common to have implementation and tests split over utils/tests/verify_action_build and utils/verify_action_build?

[potiuk]

It is common to have implementation and tests split over utils/tests/verify_action_build and utils/verify_action_build?

Yes - absolutely, this is recommended project structure (and with pyproject.toml in subdir we are heading into proper monorepo direction) - so utils will become a sub-project of the main project.

The closest we can get to "standard" in structure of the project is https://packaging.python.org/en/latest/tutorials/packaging-projects/ - this one suggests "src" as a "proper" subdirectory of utils to make it a "Python project" - however, there is an ongoing debate whether "src" or "no-src" is a better choice, and my opinion is that both are ok, depending on the purpose of the project. Some people still contest "src" and say it's "absolutely unnecessary", I think that - as everything - "it depends".

For projects that are supposed to be really "CLI / embedded tools" - no src is better choice, because when you invoke such command - via uv run for example, you avoid the pesky "src/" in path - it is much closer to starting a bash script if you will, however still it gives you a chance to split your project into way more manageable separate pieces import them from other modules and have this kind of comprehensive test suite.

For projects that are destined to be distributed as distribution packages (and this is the goal of https://packaging.python.org/en/latest/tutorials/packaging-projects/ ) - the "src" is better as it allows you to add more directories and make it easier to only choose src when preparing distributions.

In Airflow we have both (and it's fine). For example:

• https://github.com/apache/airflow/tree/main/scripts -> scripts folder that is used by CI and prek
• https://github.com/apache/airflow/tree/main/airflow-core -> airflow-core that is intended for distribution packaging and release