Release Notes

Release 5.4.0

Enhancements

  • Add flyway script generation: generate-flyway-scripts = Release Notes

Release 5.3.2

REVERSION

  • Revert vv.yaml file generation support for YAML patches due to invalid YAML generated with empty lists and null fields

Release 5.3.1

Bug Fixes

  • CKM-30676: Fix issue with collision of projectType template variable for vv.yaml

5.3.1 contains non-working vv.yaml generation and is reverted in 5.3.2

Release 5.3.0

Enhancements

  • Add the ability to patch vv.yaml`

  • Update default ckm-deployment-templates branch to Release/4.2

5.3.0 contains non-working vv.yaml generation and is reverted in 5.3.2

Release 5.2.0

Enhancements

  • Refactor generate-dibr-readme goal to be compatible with current Skaffold/Kustomize configurations

    • Use kubernetes/base/service.yaml for API Gateway port config

    • Remove unnecessary template inclusions like Consul-based instructions

  • Update generate-skaffold-file goal to always set context to . (will always live at root level)

Release 5.1.1

Refactor

  • Pull in metadata-parser-service code and remove dependency

Release 5.1.0

Enhancements

  • Merge all 4.12.x jenkins-yaml additions

Release 5.0.0

Enhancements

  • Redesign to a less opinionated, "ad-hoc", usage model

  • Rename project to ngss-filegen-maven-plugin

  • Add new internal goals to support conversion to Skaffold/Kustomize project model:

  • generate-skaffold-file

  • generate-kustomize-files

Release 4.12.0

Enhancements

  • Add support for optional Jenkins Shared Library Jenkinsfile generation via jenkinsSharedLib property, which removes need to statically generate Jenkinfiles for projects. This downloads a template that makes a call to the shared library, relying on the new jenkinsfile.yaml project file for configuration of the build.

  • Change plugin prefix to filegen

Release 4.11.0

Enhancements

  • CKM-19446 : Remove support for custom V&V stage generation in favor of standard vv-automation-image execution, thereby removing the ability to use Maven profile for local testing.

  • Upgrade Maven dependencies

Release 4.10.8

Enhancements

  • CKM-14466 : Add kustomize.enable property to have dibr.md generation use Kustomize-specific template

Release 4.10.7

Enhancements

  • CKM-14212 : Update startupProbe to use HTTP endpoint

Release 4.10.6

Enhancements

Bug Fixes

Release 4.10.5

Enhancements

  • CKM-11936 - Add support for including/excluding experimental Kustomize files

  • CKM-11715 - Archive non-Kustomize-based Kubernetes manifests when Kustomize is enabled

Release 4.10.4

Enhancements

  • CKM-10682 - Automatically generate service dependency document service_dependencies.md to assist in integration of new services

  • CKM-10554 - Download all supported remote directories to the proper local template directories

  • CKM-8689 - Add support for optional variables in documentation: consul:

Bug fixes

  • CKM-12007 - Default livenessProbe type to tcpSocket

  • CKM-10801CKM-10801 - Remove File.seperator usages since they are inconsistently applied and do not work on Windows

Notes

service-dependencies.md

In order to assist teams who do not use helm-maven-plugin + metadata.yaml to specify and deploy all necessary service dependencies automatically (e.g., if using a tool like docker-compose), the ci-file-generator plugin now generates a Markdown-formatted file that details the dependencies and corresponding configurations required for the service to operate correctly.

By default, this file is written to docs/service-dependencies.md

Reference templates by directory

When support for local template files was first added, each remote file was required to be specified in the internal configuration, so that for each added or renamed file in ckm-deployment-templates, a corresponding change would be needed to account for this in ci-file-generator. This made these components unnecessarily tightly-coupled and hard to maintain.

Now, only the directory path is needed, and every file in this directory is properly retrieved automatically.

Support for optional consul variables

A new metadata.yaml field documentation/consul/optional has been added to support generation of optional Consul variables in the docs/dibr.md document.

The syntax of this field is the same as the required field, with the environment variable name and a descriptive comment of the variable:

documentation:
  jiraProjectKey: CKM
  apigw:
    registration: none
  consul:
    required:
    - name: JWT_PUBLIC_KEY
      comment: Public key to verify JWTs
    - name: REDIS_HOST
      value: redis
      comment: The hostname for the Redis instance - no protocol or port is required
    optional:
      - name: SESSION_CACHE_PREFIX
        comment: Session cache prefix for redis hash. Default is `ses_v1:var:`.

Release 4.10.3

Enhancements

  • CKM-10711 - New Maven property to enable inclusion of the V&V stage during Jenkinsfile generation

Notes

The ability was added to explicitly enable or disable the Automated V&V Jenkins stage being generated, independent of skipVv property value. The new Maven user property named vvStageGeneration controls the generation behavior in a more finely-grained way:

  • implicit (default) - decision to generate the stage is based on whether vv.yaml generation is enabled (i.e., via skipVv or an error occuring during processing)

  • enabled - Generate the stage regardless of vv.yaml generation state

  • disabled - Do not generate the stage regardless of vv.yaml generation state

Example usage

<!-- pom.xml -->
<project>
  <!-- ... -->
  <properties>
    <vvStageGeneration>enabled</vvStageGeneration>
  </properties>
</project>
# Command-line
mvn clean install -DvvStageGeneration=enabled

Release 4.10.2

Bug Fixes

  • CKM-10116: Fix JSP verification found issues

  • Re-add helm/default-values/tcpSocketPort element back to metadata-default.yaml

  • Fix handling of ContainerSecretManagement file generation to prevent NPE

Release 4.10.1

Bug Fixes

  • CKM-10227 - Fix issue around tile-based configurations not being set via profiles in jersey-service-parent

  • Update metadata-default.yaml to set liveness and readiness to /health/ endpoints

  • CKM-10227 - Fix issue around tile-based configurations not being set via profiles in jersey-service-parent

  • Update metadata-default.yaml to set liveness and readiness to /health/ endpoints

  • Add ${vv.execution.wait} to VV tile config

Enhancements

  • CKM-9817 - Add support for Java 17

  • CKM-10086 - Create ContainerSecretManagement.md document explaining how secrets are stored for shared services

Notes

ContainerSecretManagement.md

This documentation is now generated within /fortify directory to convey how secrets are managed for the benefit of the security review process.

Release 4.10.0

Enhancements

  • CKM-8580 - Update V&V configurations for version 1.4

  • CKM-8540 - Optional kustomize-based deployment file processing via kustomize.enable property

  • CKM-7912

  • Add Mojo to create local template copies to allow for customization.

  • Add ability to override properties in pom/properties file.

  • CKM-7973 - Add warning if vault is enabled and metadata.yaml vault variables are not present

  • CKM-8189 - Ensure Slack notifications can be disabled for CKM services.

  • CKM-8303 - adding startupProbe to deployment section of the ci-file-generator

  • CKM-8392 - Add AppDynamics variables to DIBR template

  • CKM-8839 - Removing properties from tiles to avoid clashes with parent projects

  • CKM-9009 - Refactor kustomize feature to be more consistent with best practices

  • CKM-9849 - Remove AppD configuration from SQA/Staging dibr.md documentation

  • CKM-9034 - Add support for SQA/Staging canary deployment configuration

  • CKM-10086: Create re-usable document to explain how secrets are stored for services

  • Update ckm-deployment-templates branch to 3.14

Notes

Local Templating

The guide for the new local templating feature is located at https://wiki.mobilehealth.va.gov/display/CKM/Project+Artifact+Templating+Guide.

This feature allows custom templates and properties to be defined instead of relying solely on remote templates.

Kustomize Integration

The guide for the experimental preview feature that enables Kustomize to be used to manage Kubernetes resources instead of the proprietary file generation method via the ci-file-generator:generate-k8-files Maven plugin goal is located at kustomize.md.

This will eventually replace specifying project-level customizations in metadata.yaml in favor of the industry-standard application of Kustomize overlays and patches to the project’s Kubernetes manifests. If enabled via the Maven -Dkustomize.enable flag, ci-file-generator will apply the overlay located in kubernetes/overlays/dynamic (override by setting -Dkustomize.overlay) and output the resulting Kubernetes configurations to all-kustomized.yaml.

Canary (Kustomize-only) Deployments

The guide for the experimental preview feature that enables Canary deployments is located at canary.md.

Release 4.9.3

Bug Fixes

  • CKM-7875 - Ensure correct pom.xml is archived.

  • CKM-7932 - Fix issue with Sonar and V&V stages with library builds

  • Update ckm-deployment-templates branch to 3.12

Release 4.9.2

Enhancements

  • CKM-7759 - Add Jenkins build parameter for V&V Automation image version

  • CKM-7752 - Populate Fortify report URL in the generated Jenkinsfiles from the project’s own Git URL info

4.9.1

Enhancements

  • CKM-7636 - Update to support Go docker image

Notes

Support to use the new Jenkins Go build image has been added via the metadata.yaml build configuration. To have both Jenkinsfile-sandbox and Jenkinsfile specify the Go build image, whose name is set via the ${env.MAVEN_GO_BUILD_IMAGE} Jenkins environment variable, include the following in metadata.yaml:

build:
  language: go # default is 'java'

4.9.0

Bug Fixes

  • CKM-7082 - Fix Jenkinsfile generation with multiple Git remotes

Enhancements

  • CKM-7516 - Add support for exec probe type in deployment.yaml generation

  • CKM-7143 - Remove hard-coded VV contact info; map Jira project key defaults for CKM

    • Update ckm-deployment-templates to 3.10

Notes

Kubernetes deployment.yaml exec probe

Included in this release is the ability to generate a Kubernetes exec probe in the deployment.yaml manifest. For example, given the following livenessProbe provided in metadata.yaml:

deployment:
  livenessProbe:
    type: exec
    command: sh ./liveness

The following probe is generated in deployment.yaml:

livenessProbe:
  exec:
    command:
      - sh
      - ./liveness

Populate vv.yaml contact info with dynamic per-project data

Instead of hard-coding the default contact info for the vv.yaml file, now there is a JSON configuration file stored in ckm-deployment-templates that map JIRA project keys to default contact data for various fields in the contact section of vv.yaml. For instance, below is the current configuration:

{
  "projects": [
    {
      "projectKey": "ckm",
      "contacts": {
        "primary": {
          "name": "Ryan Britt",
          "organization": "Apothesource",
          "email": "Ryan.britt@apothesource.com",
          "phone": "(843) 900-7456"
        },
        "projectManager": {
          "name": "Kevin Troutner",
          "organization": "VA",
          "email": "Kevin.Troutner@va.gov",
          "phone": ""
        },
        "businessOwner": {
          "name": "Kevin Troutner",
          "organization": "VA",
          "email": "Kevin.Troutner@va.gov",
          "phone": ""
        }
      }
    }
  ]
}

The contact block properties are initially populated with these values if the JIRA project key is set to ckm in metadata.yaml, like so:

# metadata.yaml

documentation:
  jiraProjectKey: ckm
# vv.yaml
contact:
  primary:
    name: "Ryan Britt"
    organization: "Apothesource"
    email: "Ryan.britt@apothesource.com"
    phone: "(843) 900-7456"
  project_manager:
    name: "Kevin Troutner"
    organization: "VA"
    email: "Kevin.Troutner@va.gov"
    phone: ""
  business_owner:
    name: "Kevin Troutner"
    organization: "VA"
    email: "Kevin.Troutner@va.gov"
    phone: ""

These values can be edited freely after initialization.

4.8.2

Bug Fixes

  • CKM-7271 - Fix inclusion of AWS annotation in deployment.yaml

    • Update ckm-deployment-templates.branch from Release/3.8 to Release/3.9

Enhancements

  • CKM-6900 - Update metadata-default.yaml to include helm startupProbes

  • CKM-7071 - Update KubernetesMojo.java comments to depict default K8’s values for startupProbes if not overridden by metadata.file

Notes

Kubernetes startupProbe is now available to be configured in metadata.yaml. The default values are:

# metadata.yaml
deployment:
  startupProbe:
    enabled: false
    type: tcpSocket
    period: 1
    tcpSocketPort: 8080
    failureThreshold: 300