Optimize bundle size #3488
Open
Optimize bundle size #3488
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Change build context from project root to .cnab directory and use named build context for user files. This eliminates duplicate COPY layers and unnecessary RUN commands for file deletion. Key changes: - Build from .cnab directory instead of project root - Add 'userfiles' named context for accessing user bundle files - Use COPY --from=userfiles to selectively copy user files - Use COPY --chown and --chmod flags to set permissions in one step - Remove redundant RUN rm commands (handled via .dockerignore) - Eliminate 121MB duplicate layer from copying .cnab twice - Eliminate 121MB metadata layer from chgrp/chmod RUN command Result: Reduces bundle image size by ~54% (446MB → 204MB) Signed-off-by: Kim Christensen <kimworking@gmail.com>
Signed-off-by: Kim Christensen <kimworking@gmail.com>
Update documentation and templates to reflect the change from project root to .cnab directory as the Docker build context, with userfiles named context for bundle source files. Changes: - Update template.buildkit.Dockerfile to use COPY --from=userfiles - Add Build Context section to custom-dockerfile.md explaining: * How .cnab is used as build context * The userfiles named context for source files * Examples of copying from both contexts - Update BUNDLE_DIR documentation with correct COPY syntax - Update CLI help for --build-context flag - Update architecture-buildtime.md to explain build structure These changes help users understand the new build context model and provide migration guidance for custom Dockerfiles. Signed-off-by: Kim Christensen <kimworking@gmail.com>
Add new experimental feature flag to enable optimized bundle builds that reduce image size by ~54%. When enabled: - Uses .cnab directory as build context - Adds userfiles named context for bundle source files - Uses COPY --chown and --chmod flags to avoid extra layers - Eliminates redundant RUN commands When disabled (default): - Preserves backward compatibility - Uses project root as build context - Works with existing custom Dockerfiles Signed-off-by: Kim Christensen <kimworking@gmail.com>
Implement conditional logic to support both legacy and optimized bundle build processes based on the optimized-bundle-build flag. Changes in buildx.go: - Check feature flag to determine build context path - When enabled: use .cnab directory with userfiles named context - When disabled: use project root (legacy behavior) Changes in dockerfile-generator.go: - buildCNABSection() now generates different instructions based on flag - When enabled: optimized COPY with --chown/--chmod flags - When disabled: legacy COPY with separate RUN commands for permissions This ensures backward compatibility while enabling opt-in optimization. Signed-off-by: Kim Christensen <kimworking@gmail.com>
Revert test golden files and default template to match legacy (non-optimized) build behavior, which is now the default when the optimized-bundle-build feature flag is disabled. This ensures backward compatibility and that tests pass with the default configuration. Updated files: - pkg/build/testdata/*.Dockerfile (all test golden files) - pkg/templates/templates/build/buildkit.Dockerfile These files now generate Dockerfiles with: - COPY .cnab /cnab (instead of COPY . /cnab) - RUN chgrp/chmod commands for permissions - No userfiles named context Signed-off-by: Kim Christensen <kimworking@gmail.com>
Add test cases to verify the optimized bundle build behavior when the optimized-bundle-build experimental flag is enabled. New test files: - buildkit-optimized.Dockerfile: Expected output with optimized build - custom-dockerfile-optimized-expected-output.Dockerfile: Custom dockerfile with optimized build New test cases: - TestPorter_buildDockerfile_WithOptimizedBuild: Tests default Dockerfile generation with optimized build flag - TestPorter_buildCustomDockerfile_WithOptimizedBuild: Tests custom Dockerfile generation with optimized build flag These tests verify that when the flag is enabled: - Build context uses .cnab directory - COPY uses --from=userfiles for bundle files - COPY uses --chown and --chmod for permissions - No separate RUN commands for permissions Signed-off-by: Kim Christensen <kimworking@gmail.com>
Update buildPorterSection() to conditionally copy user files based on the optimized-bundle-build feature flag: - When optimized build enabled: Use COPY --from=userfiles - When disabled (legacy): Use COPY . with RUN rm porter.yaml Also updated default template to remove hardcoded COPY line, as it's now generated dynamically by buildPorterSection(). Updated test golden files to match new output format. All build tests now pass successfully. Signed-off-by: Kim Christensen <kimworking@gmail.com>
Update documentation to explain both build modes and the experimental optimized-bundle-build feature flag. Updated files: - custom-dockerfile.md: Added sections explaining default vs optimized build modes, migration requirements, and usage examples for both modes - template.buildkit.Dockerfile: Added comments explaining when to use each COPY syntax based on feature flag - architecture-buildtime.md: Updated to document both build modes, their differences, and benefits Key documentation points: - Feature flag is experimental and opt-in - Optimized build reduces image size by ~54% - Migration guide for existing custom Dockerfiles - Clear distinction between legacy and optimized behavior Signed-off-by: Kim Christensen <kimworking@gmail.com>
Convert TestHelloBundle to run with both default and optimized build modes using table-driven test cases. The test now runs twice: 1. With default build mode (backward compatible) 2. With optimized-bundle-build experimental flag enabled This ensures that both build modes work correctly end-to-end, building and executing the same bundle successfully. The optimized build flag is set via PORTER_EXPERIMENTAL environment variable, which is the standard way to enable experimental features in Porter. Signed-off-by: Kim Christensen <kimworking@gmail.com>
Update all smoke tests to validate both default and optimized build modes using table-driven test patterns. The tests now ensure the experimental optimized-bundle-build feature flag works correctly in end-to-end scenarios. - Convert TestDesiredState to use table-driven tests with both build modes - Extend TestAirgappedEnvironment test cases to include both build modes for each registry configuration scenario - Use PORTER_EXPERIMENTAL environment variable to enable the optimized build mode during test execution Signed-off-by: Kim Christensen <kimworking@gmail.com>
Add support for switching between default and optimized custom Dockerfiles when testing bundles with custom Dockerfiles. The mybuns test bundle uses a custom Dockerfile that must be updated to use the userfiles named context when the optimized build flag is enabled. Changes: - Create Dockerfile-optimized.tmpl for mybuns test bundle - Update smoke tests to dynamically switch which Dockerfile to use based on the enableOptimizedBuild flag - Tests now properly handle custom Dockerfiles for both build modes - Ensures backward compatibility while testing new optimized builds Signed-off-by: Kim Christensen <kimworking@gmail.com>
The optimized-bundle-build refactoring inadvertently changed the legacy build behavior to unconditionally remove porter.yaml from the bundle directory. This fails when using -f to specify a manifest outside the build context (e.g., -f testdata/bundles/signing/porter.yaml). Restore the original logic that only removes the manifest if it exists within the build context, using the relative path to the manifest. Signed-off-by: Claude <noreply@anthropic.com> Signed-off-by: Kim Christensen <kimworking@gmail.com>
Signed-off-by: Kim Christensen <kimworking@gmail.com>
kichristensen
force-pushed
the
optimizeBundleSize
branch
from
627d8ca to
ff29cc5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this change
Give a summary of the change, and how it affects end-users. It's okay to copy/paste your commit messages.
For example if it introduces a new command or modifies a commands output, give an example of you running the command and showing real output here.
What issue does it fix
Closes # (issue)
If there is not an existing issue, please make sure we have context on why this change is needed. See our Contributing Guide for examples of when an existing issue isn't necessary.
Notes for the reviewer
Put any questions or notes for the reviewer here.
Checklist