Developer docs

Functionality of building isolated applications

Last Updated:

The process of building isolated applications begins with the allow-list. The allow-list is a collection of applications that are eligible to take advantage of a faster CI pipeline.

Functionality

The allow-list lives in a JSON file in the vets-website repository. Entries in the allow-list have the following properties:

Name

Required

Description

rootFolder

Yes

Root folder of application(s) that lives in src/applications.

slackGroup

Yes

Slack user group of the team that owns the application.

continuousDeployment

No

Disables continuous deployment when set to false, otherwise enabled by default for applications on the allow-list. When enabled, merging a PR that only changes files in this application triggers a production deployment via the CD pipeline, pending approval from the fe-deployment-approval-team. See Continuous deployment to production for the end-to-end flow, including the approval gate, concurrency controls, and safety checks.

Once an application directory is added to the allow-list, branches with changes exclusive to those applications will see faster CI workflow runs. Branches that include changes from non-application code, or applications that aren't on the allow-list, will perform a full build and all unit tests as usual.

Example Scenarios

Application(s) on allow-list

Changed files in branch

Build Outcome

JSON
"apps": [
  {
    "rootFolder": "vaos",
    "slackGroup": "@vaos-fe-dev"
  }
]
  • src/applications/vaos/vaos-entry.jsx

  • src/applications/vaos/sass/vaos.scss

Only the vaos app is built, since all changed files are part of the app.

JSON
"apps": [
  {
    "rootFolder": "vaos",
    "slackGroup": "@vaos-fe-dev"
  }
]
  • src/applications/vaos/vaos-entry.jsx

  • src/applications/vaos/sass/vaos.scss

  • src/platform/utilities/feature-toggles/featureFlagNames.js

A full build is executed, because non-application code was changed.

JSON
"apps": [
  {
    "rootFolder": "check-in",
    "slackGroup": "@check-in-fe"
  }
]
  • src/applications/check-in/pre-check-in/routes.jsx

All check-in apps are built, since there are multiple apps in the root folder.

Testing

For isolated application builds, the Unit Tests job in the Continuous Integration workflow will only run tests belonging to the updated application(s). The Cypress E2E Tests job will only run Cypress tests for the changed application(s) as usual, with the addition of the MegaMenu Cypress test, to ensure that the header is consistent across all applications.

Build isolation

Partial (single-app) builds and full-site builds are stored at separate S3 paths (partial/<sha>/ and full/<sha>/), preventing any possibility of one overwriting the other. The path prefix is determined automatically based on whether the CI run produced a partial or full build.

Each build tarball includes a BUILD_ARTIFACT.txt metadata file that identifies the build type. Deployment scripts validate this file before executing, ensuring a partial-deploy script cannot accidentally run against a full build (or vice versa).


Help and feedback