How to work with gradle projects

How to work with gradle projects¶

This page is the generic README.md for all gradle component projects.
It focuses on setup and usage.

Setup¶

GitHub¶

Ensure that a recent git version is installed.

Consider also installing gh, the GitHub CLI tool.

JVM¶

Ensure that JVM 21 is available; we’re using AWS implementation Corretto

On a Mac, use java --version to verify that it is the default, use JAVA_HOME or similar local environment manager
(e.g. sdkman) to ensure the right version is available.

Docker¶

Ensure that Docker Desktop is installed and launched;
enable the Kubernetes cluster if local deployment using Helm is desired.

1Password¶

Ensure that 1Password CLI is installed.

Artifact Repository Credential¶

Warning

Mind the token expiry date… gradle builds will fail after that date and the token will need to be renewed.

Create a GitHub personal access token (classic),
aka a PAT, with the single scope read:package.

create the file ~/.gradle/gradle.properties:

gpr.user: ## github handle/username, eg denisa
gpr.key: ## github token created above

create a new Note GH_OCI_RO with the password set to your GitHub handle,
a colon :, and a PAT with read access to the GitHub Docker registry.

Local Usage¶

The gradle build supports:

command	effect
`./gradlew clean`	Clean all generated artifacts
`./gradlew build`	validate, build and test all artifacts
`./gradlew helmRender`	renders the helm templates for all defined purposes

The component can be deployed to a local cluster with:

op run --env-file 1Password.env -- ./gradlew helmInstallToLocal
echo "Application:"
kubectl --context docker-desktop get service application-exposed-port --namespace=accounts --output=jsonpath='{.spec.ports[0].nodePort}{"\n"}'
echo "Postgres:"
kubectl --context docker-desktop  get service postgres-exposed-port --namespace=accounts  --output=jsonpath='{.spec.ports[0].nodePort}{"\n"}'

CI/CD¶

Every push to origin triggers a build.

When the build happens on a protected branch, or another branch with a version set to a feature branch version,
versioned artifacts are published and a deployment to the first purpose, dev triggered.

The Artifact version is the topmost version defined in the CHANGELOG.md, qualified with the run id, number and attempt
for artifacts from a feature branch.

When the deployment ends, deployment of the next purpose is triggered.
Typically, this will fail as we’re enforcing a gating mechanism.

To open the gate, and allow the deployment to proceed, manually trigger the GitHub workflow Deployment Requests Approval.

then

If needed, the version number can be read from the (failed) deployment job.

or

Alternatively, the workflow can also be triggered from the command line:

gh workflow run "Deployment Requests Approval" --ref main -f chart_version=0.6.0 -f purpose=stage

How to work with gradle projects