VACMS-16853: next build branches ftw (#17154)

* add next-build as an option for requesting a content release

* only override needed form fields for content release form

* be more specific with repo roots in settings for different envs

* fix broken unit test

* fix broken integration test

* add api client for next-build

* try different file root location

* add frontend information to payload, pass info to build trigger

* add start to next-build frontend script

* update next-build-frontend.sh script

* further separate content release state machines

* remove seperate release state manager

* remove all references to simulatenous building using current pattern

* simpler build trigger within form submission

* debug Tugboat

* filename change for queue runner

* try kicking off script via cron

* add more debugging to cron run

* correct git location for next-build

* make build script executable

* cleanup code

* add documentation

* more code cleanup

* update docs to trigger after failed tugboat

* cleanup code

* Update scripts/next-build-frontend.sh

Co-authored-by: Tanner Heffner <[email protected]>

* Update scripts/next-build-frontend.sh

Co-authored-by: Tanner Heffner <[email protected]>

* Update scripts/next-build-frontend.sh

Co-authored-by: Tanner Heffner <[email protected]>

* fixes from code review

---------

Co-authored-by: Tanner Heffner <[email protected]>

.tugboat/config.yml

@@ -226,6 +226,13 @@ services:
         - mv "${TUGBOAT_ROOT}/scripts/queue_runner/queue_runner.sh" /etc/service/drupal_events/run
         - chmod +x /etc/service/drupal_events/run
 
+        # Separate process for next-build preview.
+        - mkdir -p /etc/service/next_build
+        - mv "${TUGBOAT_ROOT}/scripts/queue_runner/next_queue_runner.sh" /etc/service/next_build/run
+        - chmod +x /etc/service/next_build/run
+        # Need to make build script executable so the runner can run it.
+        - chmod +x "${TUGBOAT_ROOT}/scripts/next-build-frontend.sh"
+
       clone:
         # This j2 command is shared in both the build & clone stages. If modifying, change the other too.
         - j2 "${TUGBOAT_ROOT}/.tugboat/.env.j2" -o "${TUGBOAT_ROOT}/.env"

READMES/cms-content-release.md

@@ -116,7 +116,6 @@ sequenceDiagram
     Complete->>+Ready: Content release workflow has completed
 ```
 
-
 # Environment specific details
 
 ## BRD Production
@@ -144,6 +143,35 @@ The Tugboat and local development versions of the release content page do not tr
 
 For more information on creating or releasing content from a preview environment, see [Environments](./environments.md).
 
+### Next Build Releases
+
+The upcoming static frontend "next-build" can be rebuilt using different versions of next-build and vets-website. It
+is a simpler process than the current content-build workflow.
+
+1. Go to "/admin/content/deploy/next".
+2. If the form elements are disabled, then a lock file exists preventing another build from being triggered. You
+   can skip to step #6.
+2. Choose a version for next-build or leave at default.
+3. Choose a version for vets-website or leave at default. When content-build is releasing, these form fields might
+   be disabled. We can't change the vets-website version while another frontend build is running.
+4. Click "Release Content" to set the versions of next-build and vets-website as well as write a "buildrequest" file.
+5. A `scripts/queue_runner/next_queue_runner.sh` script continuously runs in the background looking for the
+   "buildrequest" file and then start a build if found. Locally, the script has to be triggered manually. See the
+   [caveats](#caveats) section for more information.
+6. Back on "/admin/content/deploy/next" you can view the build log via a link in the "Status" section of the
+   "Next Build Information" block.
+7. Once the build completes no new build will be triggered until you click to release content again.
+8. View the frontend at the provided "View Preview" link in the "Next Build Information" block.
+
+#### Caveats
+
+There are some caveats to the process outlined above.
+
+- **Manually running the background script** - On `ddev` the `queue_runner` scripts aren't running continuously in
+  background jobs. So you must `ddev ssh && ./scripts/queue_runner/` to kick off the content build or next build
+  release locally. In the future, it might be a good idea to use `system.d` or `supervisor` or something else to
+  keep the background jobs going locally just like on Tugoboat.
+
 ## Troubleshooting
 
 Sometimes the state gets stuck and needs to be reset.  It can be done with a drush command

config/sync/next.next_site.next_build_preview_server.yml

@@ -4,8 +4,8 @@ status: true
 dependencies: {  }
 id: next_build_preview_server
 label: 'Next Build Preview Server'
-base_url: 'http://localhost:3000'
-preview_url: 'http://localhost:3000/api/preview'
+base_url: 'http://localhost:3999'
+preview_url: 'http://localhost:3999/api/preview'
 preview_secret: secret
 revalidate_url: ''
 revalidate_secret: ''

docroot/modules/custom/va_gov_content_release/README.md

@@ -0,0 +1,13 @@
+# VA.gov Content Release
+
+va.gov is built using two separate frontend systems with a third being built:
+
+- content-build - This is the frontend for generating static content files. You can read more about the project here:
+  https://github.com/department-of-veterans-affairs/content-build
+- vets-website - This is the frontend for integrating React widgets. You can read more about the project here:
+  https://github.com/department-of-veterans-affairs/vets-website
+- next-build - This is the new frontend for generating static content files. You can read more about the project here:
+  https://github.com/department-of-veterans-affairs/next-build
+
+More detailed documentation about how these frontends are build and released can be found in the main READMEs
+directory on the [CMS Content Release](../../../../READMES/cms-content-release.md) page.