does anyone have examples they are allowed to share about using Gradle as the main tool for deployments in a multi-project setup? Currently I'm using Gradle to build our projects, but I'm also still using GitHub Actions for the actual deployment. In other words, I have several GH pipelines that in broad terms call

./gradlew build

and then perform the deployment. But with this I need to maintain in the workflow definition the same links between projects that Gradle knows about automatically. And what's worse, that's something expressed by a list of files and directories in a yaml file. So I'm wondering if there's a way to just have a single

deploy

task that leverages Gradle's project dependency model, and I'm wondering if anyone did or came across anything similar already

what do you call

deployment

in this context ? if its application deploymentm shouldn't the gradle build command provide a standalone binary containing all the necessary dependencies ? if so why do you need to replicate the projects dependencies in your workflow ? we do have a use case where we needed to know the dependency graph to avoid building things that were not changed, we built a gradle task that extracts the graph from the gradle projects themselves. each of our app build generates a selfcontained artifact (a docker image in our case) which is then deployed

We use Gradle! To „deploy“ docker images we use jib and a custom gradle plugin that actually updates the infrastructure, eg AWS using CDK (using Java). To deploy to openLiberty servers, we use the openLiberty Gradle plugin.

@Jean Helou its application deployment, but the part that needs to happen after the build command ends, in my case publishing a docker image and updating the image of a kubernetes deployment. But I need to know which services need to be redeployed

I see : you run a single build command on the whole multiproject whereas we extract the list of applications to build from gradle using a custom task, then run a build command for each application project since each build command only relates to a single app the infrastructure update is straightforward.

We use a custom workflow which either updates all services/modules, or by passing the gradle module as input command.

@Jean Helou thanks I didn’t think about that, it’s definitely an interesting approach, it could be a good hybrid to leverage some features of the ci system that would be otherwise lost with a pure Gradle solution

Yes, it can be everything or you need to specify the gradle module name in the GitHub action workflow as input parameter.

Instead of relying on your CI having kubernetes access, you could use something like https://fluxcd.io/flux/guides/image-update/ That way you only have to worry about producing and publishing the docker images in CI