LHDI's Boilerplate Instructions - department-of-veterans-affairs/abd-vro GitHub Wiki

VRO software is deployed on the Lighthouse Delivery Infrastructure (LHDI) platform, which offers tools, services, and support team.

LHDI's Java Starter Kit was used to populate this codebase (see PR #8) using Java (AdoptOpenJDK) 17 and Gradle 7.4.

LHDI's Boilerplate Setup Instructions

About

This is a Java Spring Boot application that has been created using the Lighthouse DI Java 17 Starterkit. It is intended to be used as a starting point for building Java APIs and should be customized to deliver whatever functionality is required. If no other changes have been made, this application will have these features included by default.

CI/CD Pipeline

This project comes with a skeleton Github Actions CI/CD pipeline out of the box. You can always choose to rewrite the pipeline using a different CI/CD tool; this pipeline serves as an example that you can use and run with minimal setup.

Secrets

In order to run the pipeline, you will need to create a personal access token and add it to your repository's secrets in Github. The access token should have write:packages scope.

The secrets you need to configure are

  • ACCESS_TOKEN: the personal access token
  • USERNAME: the Github username of the user who owns the access token

Default Pipeline Behavior

The default pipeline has 3 jobs, which do the following things:

  • Runs CIS benchmark tests against the application Docker image using docker-bench-security
  • Builds and tests application
  • Publishes Docker image to VA GHCR repository

Dependencies

The pipeline runs on Github's ubuntu-latest runner, which is currently Ubuntu 20.04. The Github Actions Ubuntu 20.04 documentation lists the software installed by default. To learn more about choosing a Github runner and Github-hosted runner types, see the job.<job-id>.runs-on documentation.

Software required for the pipeline but not installed by default, such as Java 17, hadolint, and spectral, is installed in the pipeline. The installation for app build dependencies is implemented as an action in <./.github/actions/setup-pipeline/action.yml>.

Deploying the Application

The pipeline does not currently deploy the application to the DI Kubernetes clusters out of the box, although this setup will be coming in the future. To learn how to deploy your applications, see the DI ArgoCD docs.

Common Errors

  1. Error: Cannot find plugin

    Error Message:

    * What went wrong:
Plugin [id: 'gov.va.starter.plugin.cookiecutter', version: '0.1.20', apply: false] was not found in any of the following sources:

- Gradle Core Plugins (plugin is not in 'org.gradle' namespace)
- Plugin Repositories (could not resolve plugin artifact 'gov.va.starter.plugin.cookiecutter:gov.va.starter.plugin.cookiecutter.gradle.plugin:0.1.20')
Searched in the following repositories:
    MavenLocal(file:/Users/aasare/.m2/repository/)
    Gradle Central Plugin Repository
    MavenRepo
    BintrayJCenter
    maven(https://palantir.bintray.com/releases)
    maven2(https://dl.bintray.com/adesso/junit-insights)
    starterBootPkgs(https://maven.pkg.github.com/department-of-veterans-affairs/lighthouse-di-starter-boot)
    nexus(https://tools.health.dev-developer.va.gov/nexus)

    Fix: Set your Github token as per the instructions in the Required Dependencies section above.

  2. Error: Failed to get resource

    Error Message:

    Failed to get resource: GET. [HTTP HTTP/1.1 401 Unauthorized: https://maven.pkg.github.com/department-of-veterans-affairs/lighthouse-di-starter-boot/starter/java/build-utils-property-conventions/starter.java.build-utils-property-conventions.gradle.plugin/0.1.32/starter.java.build-utils-property-conventions.gradle.plugin-0.1.32.pom)]

    Fix: Set your Github token as per the instructions in the Required Dependencies section above, ensure that read:packages is true.

What's Next

Once you have verified that you are able to run the application successfully, you can now start customizing the application to deliver the functionality you would like.

By default, this application assumes the use of a build, test, release cycle as defined in this development guide. Take a look at that guide to see how you can make changes, test them and get them deployed to a target environment.

The application itself is organized into the following three tiers of functionality:

  • API
  • Service (business logic)
  • Persistence

To see how each of these tiers is used by default, take a look at the Project Structure documentation.

⚠️ **GitHub.com Fallback** ⚠️