Skip to content

Fix tests silently skipped by Docker BuildKit#76

Merged
alexellis merged 1 commit into
openfaas:masterfrom
welteki:fix-tests-skipped-by-buildkit
Apr 13, 2026
Merged

Fix tests silently skipped by Docker BuildKit#76
alexellis merged 1 commit into
openfaas:masterfrom
welteki:fix-tests-skipped-by-buildkit

Fix tests silently skipped by Docker BuildKit

cfa05ea
Select commit
Loading
Failed to load commit list.
reviewfn / succeeded Apr 13, 2026 in 1m 13s

AI Code Review Results

AI Pull Request Overview

Summary

  • Removed separate FROM build AS test stage from all template Dockerfiles to prevent Docker BuildKit from skipping test execution.
  • Moved test commands directly into the build stage, ensuring tests run when TEST_ENABLED=true since ship depends on build.
  • Changed default value of TEST_ENABLED from true to false across all templates, making testing opt-in.
  • Updated README.md and handler_test.py comments in all templates to reflect the new opt-in testing behavior.

Approval rating (1-10)

9

Summary per file

Summary per file
File path Summary
README.md Updated testing documentation to indicate testing is disabled by default and must be explicitly enabled.
template/python3-flask-debian/Dockerfile Removed test stage, moved test execution to build stage, changed TEST_ENABLED default to false.
template/python3-flask-debian/function/handler_test.py Updated comment to instruct enabling tests via TEST_ENABLED=true.
template/python3-flask/Dockerfile Removed test stage, moved test execution to build stage, changed TEST_ENABLED default to false.
template/python3-flask/function/handler_test.py Updated comment to instruct enabling tests via TEST_ENABLED=true.
template/python3-http-debian/Dockerfile Removed test stage, moved test execution to build stage, changed TEST_ENABLED default to false.
template/python3-http-debian/function/handler_test.py Updated comment to instruct enabling tests via TEST_ENABLED=true.
template/python3-http/Dockerfile Removed test stage, moved test execution to build stage, changed TEST_ENABLED default to false.
template/python3-http/function/handler_test.py Updated comment to instruct enabling tests via TEST_ENABLED=true.

Overall Assessment

The changes correctly address the issue with Docker BuildKit silently skipping tests by integrating test execution into the build stage, which is a prerequisite for the final ship stage. Making testing opt-in by default is a sensible performance optimization. The modifications are consistent across all four template variants and align with the PR description. No regressions or security concerns identified.

Detailed Review

Detailed Review

Dockerfile Changes

All four Dockerfiles (python3-flask, python3-flask-debian, python3-http, python3-http-debian) have identical changes:

  • Removal of FROM build AS test eliminates the unused stage that BuildKit optimizes away.
  • Relocation of the conditional test run (RUN [ "$TEST_ENABLED" = "false" ] && echo "skipping tests" || eval "$TEST_COMMAND") from the test stage to the build stage ensures execution when enabled.
  • Changing ARG TEST_ENABLED=true to ARG TEST_ENABLED=false enforces opt-in testing, preventing unintended build delays.

This approach resolves the core issue without introducing new dependencies or altering the build process for users who disable tests.

Test File Comment Updates

Each handler_test.py file updated the comment from "To disable testing..." to "To enable testing...", with the corresponding build_arg change from TEST_ENABLED=false to TEST_ENABLED=true. This accurately reflects the new default behavior and provides clear guidance for users.

README.md Update

The testing section now states "Testing is disabled by default and must be explicitly enabled," which is accurate and helps users understand the change. The examples for enabling tests via CLI or YAML remain unchanged and correct.

Potential Considerations

  • No impact on existing functions that explicitly set TEST_ENABLED=true in their configuration.
  • The change may surprise users who relied on default test execution, but the opt-in approach is preferable for CI/CD performance.
  • All templates maintain consistency, reducing confusion.

No code issues, security risks, or performance regressions observed.

AI agent details.

Agent processing time: 1m6.693s
Environment preparation time: 5.726s
Total time from webhook: 1m14.978s