-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: allow occam to cope with pack limitations #339
Conversation
pack seems to be very limited in the options it will accept when building for multi-arch. It does not seem to accept a path with a tgz as input and only works properly if you build in an exploded directory. Otherwise it appears to have built the cnb file but the structure of the bin directory is incorrect and the executables cannot be found. Update the jam packager to work around this by exploding the tgz after creating it and then build in that exploded directory. It is still a good idea to build the tgz as that filters the files based on what is specified in the buildpack.toml. Signed-off-by: Michael Dawson <[email protected]>
@ForestEckhardt any chance you could take a look, we need this to progress on getting Node.js buildpacks to support multi-arch. |
@robdimsdale any chance you could take a look? |
@ForestEckhardt, @robdimsdale any chance one of you two could take a look? |
Should we address this at the source (i.e. |
@ForestEckhardt the real fix is for pack to better support multi-arch so that all of the different options/use cases it supports for non-multiarch work but that is a much bigger effort that what is in this PR. In this case I think jam just calls pack passing through some of the options provided by occam so it seems more confusing to me to try to add the work around in jam that says even through I called you with these pack options, convert the input and options to something else before calling pack. |
@mhdawson So |
I'm going to look at updating jam to see how that works out. |
After looking at changing jam insead for a bit, it looks like its more complicated that we thought. The tar creation is based of a list of files with access rights, timestamps and a directory structure. It would take more than just not zipping to create a copy that would ensure we get the same result. |
pack seems to be very limited in the options it will accept when building for multi-arch. It does not
seem to accept a path with a tgz as input and only works properly if you build in an exploded directory. Otherwise it appears to have built the cnb file but the structure of the bin directory is incorrect and the executables cannot be found.
Update the jam packager to work around this by exploding the tgz after creating it and then build in that
exploded directory.
It is still a good idea to build the tgz as that
filters the files based on what is specified in the buildpack.toml.
The unit tests pass, but more integration testing might be good. Once I have confirmation that people
are comfortable withe the PR I'll manually test on a few existing buildpacks in addition to the testing I've
already done on the npm-install buildpack modified for multi-arch -> https://github.com/mhdawson/npm-install/tree/test-multi (Note that this needs an updated jam that includes an updated packit with this change - paketo-buildpacks/packit#604)
Summary
Allow the ability to test buildpacks that have been updated to support multi-arch. Occam will still only test on the one architecture as the machine the tests are run on but with the update can run tests for buildpacks that support multi-arch, or buildpacks that don't.
Use Cases
Testing buildpacks that support multi-arch
Checklist