Creating a vets-website Release

If the commit you are trying to release to does not have an official release tag, you have to create one:

  1. Update your local main branch

  2. Check out the commit you want

  3. Note the latest release from the vets-website release log (the tag will look like vets-website/v0.1.1888)

  4. Make sure the commit you want to use has passed through the build pipeline in main and note the commit SHA (it will be a long string like 46fd8ecdd6b836e7f737c43981274d68e5b70262 or the shortened version like 46fd8ec)

  5. Run git tag NEW_VERSION COMMIT_SHA && git push origin NEW_VERSION replacing NEW_VERSION with the next patch version after the previously noted version (vets-website/v0.1.1888 becomes vets-website/v0.1.1889) and COMMIT_SHA with the previously noted long or short commit SHA

  6. You should now see it in the vets-website release log and can follow the normal rollback steps.

This should create a new release, and deploy it to VA.gov.

Creating a content-build Release

If the commit you are trying to release to does not have an official release tag, you have to create one:

  1. Update your local main branch

  2. Check out the commit you want

  3. Note the latest release from the content-build release log (the tag will look like content-build/v0.0.1251)

  4. Make sure the commit you want to use has passed through the build pipeline in main and note the commit SHA (it will be a long string like 2c58be841b801404a51602e7c274ef0f8aa1a5dc or the shortened version like 2c58be8)

  5. Run git tag NEW_VERSION COMMIT_SHA && git push origin NEW_VERSION replacing NEW_VERSION with the next patch version after the previously noted version (content-build/v0.0.1251 becomes content-build/v0.0.1252) and COMMIT_SHA with the previously noted long or short commit SHA

  6. You should now see it in the content-build release log and can follow the normal rollback steps.

This should create a new release, and deploy it to VA.gov .

Note: Verify that there are no scheduled content releases around the time of creating a release. A following release can override your manual release if started before your release has finished.

Hotfixes

The use of hotfixes is discouraged, but may be useful in an emergency situation when main has significantly deviated from the release and a fix to the failed production release is critical. To create a hotfix, create a branch from the last stable release tag, make changes necessary (with review), create a new release tag following the correct naming scheme, and trigger a deploy in GitHub Actions with the release name as a parameter.


Feedback and support