Skip to content
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

Test integration between Spring Boot image building and Paketo buildpacks #25824

Closed
scottfrederick opened this issue Mar 29, 2021 · 2 comments
Closed
Assignees
Labels
type: task A general task
Milestone

Comments

@scottfrederick
Copy link
Contributor

We'd like to introduce a new set of tests that verify the integration between the Spring Boot image building plugins and the Paketo buildpacks.

We currently have Gradle BootBuildImageIntegrationTests and Maven BuildImageTests that test the build plugins by invoking the full stack required for building an image - Docker Engine, CNB builder, buildpacks, etc. These tests are designed to only test that the plugins respond to configuration options and invoke a builder as expected, without assuming too much about a specific CNB implementation.

The new integration tests would be designed to inspect the built images much more deeply, to verify that the contract between the plugins and the Paketo buildpacks is met. This would include inspecting image labels, layer content, etc. These tests would be triggered by a Paketo builder being published, not on each commit to Spring Boot.

This approach could be expanded to other CNB builder and buildpack implementations in the future.

@philwebb
Copy link
Member

For some reason this update seems to make Eclipse grumpy. I don't think it can resolve the project dependencies in spring-boot-test-support. I suspect there might be a project tangle that Gradle can deal with and Eclipse cannot.

I think we should consider pruning some of the dependencies and pushing them to the sub projects. AFAICT they're mostly needed in GradleBuild.pluginClasspath(). I think we add a constructor that takes a list of classes or make pluginClasspath() protected and override it in the sub projects. IMO it would be good to keep spring-boot-test-support as a base project that all the other projects (including the loader and buildpack-platform) can use.

@philwebb philwebb reopened this Jul 14, 2021
@scottfrederick
Copy link
Contributor Author

scottfrederick commented Jul 14, 2021

We're going to move all the Gradle related code that was added to spring-boot-test-support into a separate spring-boot-gradle-test-support module to simplify both modules and eliminate module tangles. We can look at making the classpath changes mentioned above as part of the separation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: task A general task
Projects
None yet
Development

No branches or pull requests

2 participants