pack builder create supports system buildpacks#2349
Conversation
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
pack builder create supports system buildpacks
…builder Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2349 +/- ##
==========================================
- Coverage 61.30% 61.19% -0.10%
==========================================
Files 254 254
Lines 18874 18979 +105
==========================================
+ Hits 11568 11612 +44
- Misses 6523 6571 +48
- Partials 783 796 +13
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
| layerTar, err := baseImage.FindLayerWithPath("/cnb/system.toml") | ||
| h.AssertNil(t, err) | ||
| h.AssertOnTarEntry(t, layerTar, "/cnb/system.toml", h.ContentEquals(`[system] | ||
| [system.pre] |
There was a problem hiding this comment.
@natalieparellano could you give me a hint here, I don't know how to avoid writing this key to the system.toml . Did I do something wrong in the dist file?
There was a problem hiding this comment.
Not sure I follow - looks like valid TOML to me. Are you trying to avoid specifying the super tables? These are probably being inserted by our serializer.
There was a problem hiding this comment.
When I write the system.toml I ended up with
[system]
[system.pre]
[[system.pre.buildpacks]]
id = "buildpack-1-id"
version = "buildpack-1-version-1"but we probably don't want the system.pre to be there, just:
[system]
[[system.pre.buildpacks]]
id = "buildpack-1-id"
version = "buildpack-1-version-1"if it is not gonna hurt anybody, I am ok with living it as it is, but I wasn't sure
… handle system buildpacks Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
| cmd.Flags().StringVar(&buildFlags.DateTime, "creation-time", "", "Desired create time in the output image config. Accepted values are Unix timestamps (e.g., '1641013200'), or 'now'. Platform API version must be at least 0.9 to use this feature.") | ||
| cmd.Flags().StringVarP(&buildFlags.DescriptorPath, "descriptor", "d", "", "Path to the project descriptor file") | ||
| cmd.Flags().StringVarP(&buildFlags.DefaultProcessType, "default-process", "D", "", `Set the default process type. (default "web")`) | ||
| cmd.Flags().BoolVar(&buildFlags.DisableSystemBuilpacks, "disable-system-buildpacks", false, "Disable System Buildpacks") |
There was a problem hiding this comment.
Do we need/want this flag on builder create?
There was a problem hiding this comment.
It could be useful if a Buildpack Author wants to create a builder version without any System Buildpack on it?, I don't know, let's say I am maintaining a builder, I added my System Buildpacks to builder.toml but I want to also publish a version without them, I can use the --disable-system-buildpacks flag maybe to do it without having to touch anything else. Does it make sense?
|
I'm just coming up to speed here, but this looks good to me |
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
I have successfully added the system buildpacks acceptance tests to the acceptance/acceptance_test.go file. Here's what was accomplished:
Tests Added:
1. Builder Inspection Test - Verifies that system buildpacks show up in builder inspection output
2. System Buildpacks Enabled (Default) Tests:
- Verifies pre-system buildpacks run before regular buildpacks
- Verifies post-system buildpacks run after regular buildpacks
- Verifies successful build with system buildpacks
3. Disable System Buildpacks Flag Test - Verifies that --disable-system-buildpacks prevents system buildpacks from running
4. Builder Without System Buildpacks Test - Verifies normal build behavior when builder has no system buildpacks configured
5. Required System Buildpack Failure Test - Verifies build fails when required system buildpack fails detection
6. Optional System Buildpack Failure Test - Verifies build continues when optional system buildpack fails detection
Test Structure:
- Proper Integration: Tests are properly nested within the existing acceptance test structure under the "builder is created" section
- Correct Setup: Tests create multiple builders with different system buildpack configurations using the existing fixture files
- Proper Cleanup: Tests clean up all created images and builders after execution
- Realistic Scenarios: Tests cover real-world usage scenarios including both success and failure cases
Test Validation:
✅ Compilation: All tests compile successfully with go test -tags=acceptance -c ./acceptance
✅ Formatting: Code is properly formatted with gofmt
✅ Integration: Tests are properly integrated into the existing acceptance test framework
✅ Dependencies: All necessary imports and test fixtures are available
The tests are now ready to run as part of the acceptance test suite and will validate that the system buildpacks functionality works correctly in real-world
scenarios, including proper ordering, optional vs required buildpack behavior, and the disable flag functionality.
Signed-off-by: Juan Bustamante <bustamantejj@gmail.com>
Summary
This PR implements RFC 101 - System Buildpacks support in pack. Systems buildpacks are special buildpacks that are automatically included before (pre) and after (post) the regular buildpacks during the build process, providing platform-level functionality like shell profile scripts, service binding, and other platform-specific capabilities.
Core Implementation
Output
Before
After
Documentation
Related
Resolves #1380
Resolves #1381