Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DOCS] Updates README with information about content-build #15961

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -88,7 +88,7 @@ The VA.gov CMS Team

### About the CMS

This repository hosts the source code for the _Content Management System_ (**CMS** or **CMS-API**) utilized by [VA.gov](https://www.va.gov).
This repository hosts the source code for the _Content Management System_ (**CMS** or **CMS-API**) utilized by [VA.gov](https://www.va.gov).

The production instance can be found at [prod.cms.va.gov](https://prod.cms.va.gov/). Please note that access to the production CMS is limited; refer to [Getting Access](READMES/access.md) for more information.

Expand Down Expand Up @@ -124,7 +124,7 @@ The production instance of the CMS is utilized in two main ways:

#### Build and Release Process

In a continuous integration context, the `content-build` project is managed as a dependency of the CMS project; the build script is executed targeting the local instance and runs all of the content queries performed as part of the normal content release process, to ensure no changes have been introduced to the CMS codebase that break compatibility. A full content build happens at the conclusion of the testing pipeline on our [Tugboat](https://tugboat.qa/) preview environments.
In a continuous integration context, the `content-build` project is managed as a dependency of the CMS project; the build script is executed targeting the local instance--the database and code of which is from the day before--and runs all of the content queries performed as part of the normal content release process, to ensure no changes have been introduced to the CMS codebase that break compatibility. A full content build happens at the conclusion of the testing pipeline on our [Tugboat](https://tugboat.qa/) preview environments.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't correct. The database and code are current at the time the build script is run in a CI context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@ndouglas ndouglas Nov 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Steve's comment is referring to the content-build repository's CI process. This section is referring to the va.gov-cms repository's CI process.

In the content-build repository's CI process, the build script is not managed as a dependency of the CMS project and is not executed targeting the local instance of the CMS; there is no local instance.


In the normal content release process, GitHub Actions triggers a workflow that targets a mirror (hosted in [Tugboat](https://tugboat.qa/)) of the production CMS instance. It retrieves content from the [CMS](https://cms.va.gov) via GraphQL (and other sources) and generates HTML, CSS, JavaScript, and images. These artifacts are then copied to an s3 bucket, which is then rotated into service to serve website visitors.

Expand Down
Loading