Upgrade Spring Boot & Gradle Wrapper versions across the board

[dmikusa]

Summary

Update everything in one PR.

Use Cases

Checklist

• I have viewed, signed, and submitted the Contributor License Agreement.
• I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
• I have added an integration test, if necessary.
• I have reviewed the styleguide for guidance on my code quality.
• I'm happy with the commit history on this PR (I have rebased/squashed as needed).

[anthonydahanne]

is it stuck because of Spring Boot gradle upgrades?

[dmikusa]

is it stuck because of Spring Boot gradle upgrades?

No, this one is stuck because of caching problem. We cache all of the gradle/maven downloads on the host runner and then volume map those into the build containers so that each application doesn't need to re-download the world.

This requires getting the permissions correct so that the build containers can write to these locations. At the moment, that is failing and it can't write. It was working, so something has changed but we're not sure what yet. When this happened previously, something had changed in the Github Ubuntu "latest" image.

Basically, someone has to go through and check permissions/ownership outside of the container and inside of the container and then compare the two. Hopefully, we can spot what changed and adjust the workflow.

[dmikusa]

Thoughts

[anthonydahanne]

Hello @dmikusa
So this is what I want to generalize for all Java samples (for now just 2)
https://github.com/paketo-buildpacks/samples/actions/runs/6294008765
Continuing refactoring the other samples

[dmikusa]

Hello @dmikusa So this is what I want to generalize for all Java samples (for now just 2) https://github.com/paketo-buildpacks/samples/actions/runs/6294008765 Continuing refactoring the other samples

That's interesting, so instead of using the trigger to execute the workflow based on the path, you have one workflow that runs and then determines what to execute and kicks off other things via a matrix. Did I follow that right?

I don't have strong feelings about the approach so long as we are only testing things that have changed. I do generally have an aversion to lots of inline bash. We have that in a few places and it's a nightmare to maintain. You might want to consider replacing that with an action (i.e. some Go code and unit tests).

If your concern with generalizing stuff is reducing duplication in the workflows, you might also consider a reusable workflow.

[anthonydahanne]

That's interesting, so instead of using the trigger to execute the workflow based on the path, you have one workflow that runs and then determines what to execute and kicks off other things via a matrix. Did I follow that right?

That is correct: there's the first job, named prepare that uses git history to find out what are the Java samples that got changed, then it creates a list (as seen in the run summary) of all the Java samples paths that do have a smoke_test folder and have changed. Then, a job running smoke_test will be created for each element of the list.

I don't have strong feelings about the approach so long as we are only testing things that have changed.

Right, this is exactly what it does

I do generally have an aversion to lots of inline bash. We have that in a few places and it's a nightmare to maintain. You might want to consider replacing that with an action (i.e. some Go code and unit tests).

I understand your concern. I usually also dislike bash scripts for anything bigger than 3 lines of code; but...

• I started with bash re using some logic I already successfully (as in no maintenance) implemented on another project
• the situation is critical for the samples nothing runs for Java; I don't like to use the emergency argument, but rewriting in Go with an image published, etc. well, it will push the fix further away I believe...

If your concern with generalizing stuff is reducing duplication in the workflows, you might also consider a reusable workflow.

oh, interesting; but my concern was not only about copy/pasting (which re usable workflows in a way solve); but also in the fact of creating a test-pull-request-XXX.yml for every and each project; which reusable workflows won't solve unfortunately

[dmikusa]

I understand your concern. I usually also dislike bash scripts for anything bigger than 3 lines of code; but...

Yes, I get the time crunch here. My counter-proposal would be make sure it's using set -eo pipefail at the top and very heavy comments in the bash script. Explain what everything is doing.

[anthonydahanne]

pretty much all set now @dmikusa .

I'll rebase it on #625 once it's merged (it will fix the only failing smoke test) and then we're good I believe!

[dmikusa]

It's looking good. Only question. I see that the caching host-level caching for Gradle/Maven was removed. Even splitting things up, that's going to help speed up runs. The download time for dependencies is about 1/3 of the build time for Java apps (non-native). Still seems significant. Wondering your thoughts on removing it.

[anthonydahanne]

Hello 👋

I see that the caching host-level caching for Gradle/Maven was removed. Even splitting things up, that's going to help speed up runs.

What caching precisely are you referring to?

In any way, I believe caching for the samples to not be helping.
Sure, we could save some seconds here and there; but this is not what our users are going to experience when they use the paketo buildpacks on their machines: they'll go through long downloads and potential missing artifacts. As we've ourselves experienced recently some discrepancies between the cached samples and samples builds from scratch, caching can in our case hide environmental issues that we need to notice before our users do.