Ability to choose frontend WEB branch on content rebuild/deploy

[indytechcook]

The UI at admin/content/deploy there should be a drop down and button to change the front end branch.

Tech Note:

• Add a form to the Environment Plugins to control what is shown

AC:

• CMS user with can change the front-end branch to test a new PR
• Branch change will trigger a new composer install
  - [ ] Branch change will show progress bar to user Moved to (Content Release Job status #3577 )
  - [ ] Remove /va/deploy steps from tests.yml Moved to (Remove /va/deploy steps from tests.yml #3904)
• Branches and tags are pulled in from github for vets-webite
• branch selection should only be shown on tugboat envirnments

[indytechcook]

This is required for demo sites on tugboat.

[acrollet]

ok, I have a half-baked idea for the queue runner piece, here's a rough diagram:

Going in order:

• I didn't seriously consider realtime notification mechanisms other than redis since:
  • I believe we want to move towards using it for caching anyway
  • it's a very robust solution and available on AWS
• Alternatives to amphp
  • ReactPHP - appears to be somewhat less actively maintained. The amphp coding style is said to be cleaner and easier to read.
  • Swoole - additional server requirements, higher lift to implement in tugboat & BRD
• I don't have a super strong feeling either way about bootstrapping drupal in the task runner vs calling out to drush to process queue items. That said, it keeps things less tightly coupled and may incur less tech debt to keep the task runner as simple as possible. (Also lowers the possibility for memory leaks etc. in the long-running process)
• We can also consider creating a node.js task runner instead if we're making drush do the lifting for the queue processing.

[indytechcook]

A few things to consider:

• This solution only needs to work on tugboat. We can reevaluate when we work on near real-time notifications. We just need to make sure the docker instance is as close to production as we can get and we don't bootstrap code that requires external services on BRD.

  • The listen processes must either run on the same docker container as drupal or call out to the drupal container since all of the web code lives on this server for now.
  • When we do setup a listener services on BRD it will run on a separate server than the webheads.
  • Regarding Swoole, this is IMO the best solution. Let's not let server requirements dictate software selection. To get a long-running service up on BRD is already a significant effort and adding Swoole does not increase that effort. That being said, we are not going to get a long-running service up on BRD yet and I do not want to make the Drupal docker image defer any more from matching BRD. So this isn't the best solution yet.
  • We can make most of our code independant of the underlying library.

• Redis is awesome, unfortunately redis on ElasticCache isn't.

  • Redis is single-threaded. In a self-hosted EC2, we would launch an intense of redis for each processor/core on the server. Then a redis cluster process is stuck in front on the same server.
  • With ElasticCache, each EC2 instance launched is a single redis process so to utilize multiple threads a cluster must be setup in ElasticCache which is significantly more expensive.
  • ElasticCache throttle bandwidth based upon the EC2 instance selected. Adding more to the cost.
  • Redis is also a blocking operation so if there is a process that launches a long-running redis call then it can bring all of Drupal down if not using a cluster. (been there)
  • The queue backend should not change our code. The backend should be a configuration which can changed between local/tugboat/BRD.

• When we move to put Drupal cache out of the database, Memcache is probably the best bet due to Redis limitation on ElasticCache.

• In a post implementation of a long running event service in D7 I use pcntl_fork

  • In the main process I set up the listener to RabbitMQ
  • When a new message came in a new process was forked and the code was run.
  • This was was which used the main Drupal code was as a dependcie.
  • It was slow due to Drupal having to be bootstrapped in the child process due to how the REQUEST_TIME variable worked in core.