Merge branch 'chore/docs-updates' into 'master'

(Chore) docs updates

See merge request minds/oss-website!3

README.md

@@ -8,6 +8,8 @@ These docs were created with [Docusaurus](https://docusaurus.io/).
 
 1. Make sure all the dependencies for the website are installed:
 
+In oss-website\website
+
 ```sh
 # Install dependencies
 $ yarn

docs/guides/backend.md

@@ -240,15 +240,109 @@ Make sure you include `@package Minds\Core\<<VideoChat>>` in `<<VideoChat>>.php`
 ### Executing
 
 To run all tests:
- * `bin/phpspec run`
+```console
+bin/phpspec run
+```
 
 
 To run a specific spec file (or folder), add its name:
- * `bin/phpspec run Spec/Core/VideoChats/Repository.php` 
+```console 
+bin/phpspec run Spec/Core/VideoChats/Repository.php
+``` 
 
 
 To run a specific test inside of that spec file, add its starting line number:
- * `bin/phpspec run Spec/Core/VideoChats/Repository.php:42` 
+```console
+ bin/phpspec run Spec/Core/VideoChats/Repository.php:42`
+```
+
+### Verbose output
+Runing this command will give you deep output of the testes
+
+```console
+bin\phpspec run -vvv 
+```
+
+## Writing new tests
+
+### Creating a Spec.php file
+
+Run this command to create a test skeleton in the appropriate place with the default classes imported.
+
+```console
+bin/phpspec run Minds/Your/Namespace/ClassYouWantToSpec
+```
+
+This will create a folder in *minds/engine/
+
+### Mock everything
+
+There's a lot going on under the hood in the modules, some of them have low level connectivity to the data stores. If you don't own the object, mock it. Prophesy makes it really easy
+
+Phpspec provides easy ways to create mocks.
+
+Inside your unit test, be sure to import the class you want to mock.
+
+### Mocking at the test class level
+
+Phpspec provides a *let* function that gets run before each test. If you provide a typed parameter, it will be mocked to the matching namespace.
+
+
+
+```php
+use PhpSpec\ObjectBehavior;
+use Minds\Entities\Entity;
+
+class ManagerSpec extends ObjectBehavior {
+ protected $entity;
+
+ let(Entity $entity) {
+ //Store a reference to the mock for reuse.
+ $this->entity = $entity 
+ }
+}
+```
+
+### Mocking at the test function level
+
+Phpspec will provide mocks via function parameters in your test
+
+```php
+use PhpSpec\ObjectBehavior;
+use Minds\Entities\Entity;
+
+class ManagerSpec extends ObjectBehavior {
+
+ public function it_should_run_test(Entity $entity) {
+ 
+ }
+}
+```
+
+### Setting Expectations
+
+These mockable objects can then configured to simulate what will happen with special functions available on the mock.
+
+ShouldBeCalled will set the expectation that mocked method should be called with a parameter.
+```php
+ $entity->setGuid(123)->shouldBeCalled();
+```
+
+willReturn simulates the response of a mocked method
+```php
+ $entity->setGuid(123)->willReturn($entity);
+```
+
+### Getting to the underlying object
+
+Sometimes, php will choke on the reflection of these mocked objects (especially when constructing other objects). 
+
+```php
+ //This will instantiate an object and still be mockable.
+ $mockedObject->getList()->willReturn([]);
+ $service = new ServiceThatNeedsDependencies($mockedObject->getWrappedObject());
+```
+
 
 # Controllers
 > TODO

docs/guides/deployment.md

@@ -17,6 +17,29 @@ docker build -t minds/fpm:latest -f containers/php-fpm/Dockerfile .
 docker build -t minds/runners:latest -f containers/php-runners/Dockerfile .
 ```
 
+## Getting connected to the staging environment
+
+### Prerequisties
+* Your AWS access keys setup in your environment
+ * AWS_ACCESS_KEY={Your access key provided by Mark}
+ * AWS_SECRET_ACCESS_KEY={Your secret access key provided by Mark}
+ * AWS_DEFAULT_REGION=us-east-1
+* Your AWS user must have access to AWS EKS
+* Helm and Kubernetes installed
+
+### Connecting
+
+```console
+aws eks update-kubeconfig --name=sandbox
+
+export KUBECONFIG=$HOME/.kube/config
+```
+Then you should be able to see all available pods with:
+
+```console
+kubectl get pods
+```
+
 ## Review Apps
 
 The review apps make use of [Helm](https://helm.sh) and [Kubernetes](https://kubernetes.io/). Our helm charts can be found [here](https://gitlab.com/minds/helm-charts) and you can inspect the review app auto deployment in our [.gitlab-ci.yml file](https://gitlab.com/minds/engine/blob/master/.gitlab-ci.yml#L52).
@@ -49,6 +72,70 @@ helm upgrade \
  ./helm-charts/minds
 ```
 
+### Managing settings on the Review Apps
+
+When a pod gets deployed, [Helm charts](https://gitlab.com/minds/helm-charts) writes in the values by parsing the [configMap.yaml](https://gitlab.com/minds/helm-charts/blob/master/minds/templates/configMap.yaml). 
+
+To have your values persist across builds, you must extend the settings.php script in the (configMap.yml) (https://gitlab.com/minds/helm-charts/blob/master/minds/templates/configMap.yaml)
+
+Do not hard code the values in the configMap, reference them via *.Values.key.subkey*:
+
+```
+ // Twillio configuration
+ $CONFIG->set('twilio', [
+ 'account_sid' => '{{ .Values.twilio.sid }}',
+ 'auth_token' => '{{ .Values.twilio.token }}',
+ 'from' => '{{ .Values.twilio.from }}'
+ ]);
+
+```
+
+And add the values to the correponding yaml files
+[Staging environment defaults](https://gitlab.com/minds/helm-charts/blob/master/minds/values.yaml)
+[Production values](https://gitlab.com/minds/helm-charts/blob/master/minds/values-production.yaml)
+
+
+
+
+### Why so many values and templating?
+Because it enables us to do something really cool, like dynamically override configuration values for your staging environment - useful for turning on your feature flags.
+
+You can test your *local changes* and manipulate the staging environments by using the helm-charts repo. Create your branch, make your changes and then, inside your helm-charts repository branch, run:
+
+```
+ helm upgrade --reuse-values --recreate-pods --set new.key='new value' --wait 
+ {your.staging.site.subdomain} ./minds
+```
+
+So changing an **existing** configuration value is as simple as:
+```console
+helm upgrade --install --recreate-pods --reuse-values --set max_video_length=12600 feat-max-video-size-1506 ./minds/
+```
+
+Adding a new value requires a bit more leg work. Create a new branch in helm charts and add your values to configMap.yaml and values.yaml. Then, you can:
+
+```console
+helm upgrade --install --recreate-pods --reuse-values feat-max-video-size-1506 ./minds/
+```
+
+We don't need to specify a set value here because the value doesn't exist. However, once you set it, it will continue to be inherited from the last release because of --reuse-values and you'll need to update it with set.
+
+If you hose anything, you can always re-run the pipeline which will rebuild the pods with the latest configuration in master and start over.
+
+## Interacting with the Staging environment
+
+You can get access to the pods by using **kubectl**. Note, pods are read-only and ephemeral, so you can't go hacking things on the container.
+
+Get a list of all pods
+```console
+kubectl get pods
+```
+
+Shell into a pod using the name from ```get pods``` (read only)
+```console
+kubectl exec -it {your.staging.site.subdomain}-{pod.type}-{kubernetes-suffix} sh 
+```
+
 ## Production
 
-The Minds production environment is deployed directly from the CI flow found [here](https://gitlab.com/minds/engine/blob/master/.gitlab-ci.yml#L97). Minds currently uses Docker/ECS, but plans to move to Kubernetes as soon as possible. 
\ No newline at end of file
+The Minds production environment is deployed directly from the CI flow found [here](https://gitlab.com/minds/engine/blob/master/.gitlab-ci.yml#L97). Minds currently uses Docker/ECS, but plans to move to Kubernetes as soon as possible. 

website/i18n/en.json

@@ -3,7 +3,7 @@
  "localized-strings": {
  "next": "Next",
  "previous": "Previous",
- "tagline": "A website for testing",
+ "tagline": "The Minds Stack",
  "docs": {
  "contributing/contributing": {
  "title": "Contributing"