Moer tidy ups

cloudfoundry · richard-cox · Aug 7, 2020 · Jul 13, 2020 · Jul 13, 2020 · Jul 20, 2020
commit 7147c81a1577f1e5a61e94753426b83a731d781a
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -1,12 +1,12 @@
-# Contributing to Stratos UI
+# Contributing to Stratos
 
-Stratos UI is an open project and welcomes contributions. These guidelines are provided to help you understand how the project works and to make contributing smooth and fun for everybody involved.
+Stratos is an open project and welcomes contributions. These guidelines are provided to help you understand how the project works and to make contributing smooth and fun for everybody involved.
 
 There are two main forms of contribution: reporting issues and performing code changes.
 
 ## Reporting Issues
 
-If you find a problem with Stratos UI, report it using [GitHub issues](https://github.com/cloudfoundry/stratos/issues/new).
+If you find a problem with Stratos, report it using [GitHub issues](https://github.com/cloudfoundry/stratos/issues/new).
 
 Before reporting a new issue, please take a moment to check whether it has already been reported
 [here](https://github.com/cloudfoundry/stratos/issues). If this is the case, please:
@@ -29,7 +29,7 @@ This information will help to determine the cause and prepare a fix as fast as p
 ## Code Changes
 
 Code contributions come in various forms and sizes, from simple bug fixes to implementation
-of new features. Before making any non-trivial change, get in touch with the Stratos UI developers first. This can prevent wasted effort later.
+of new features. Before making any non-trivial change, get in touch with the Stratos developers first. This can prevent wasted effort later.
 
 To send your code change, use GitHub pull requests. The workflow is as follows:
 
@@ -43,7 +43,7 @@ To send your code change, use GitHub pull requests. The workflow is as follows:
 
   1. Publish the branch and create a pull request.
 
-  1. Stratos UI developers will review your change and possibly point out issues.
+  1. Stratos developers will review your change and possibly point out issues.
      Adapt the code under their guidance until all issues are resolved.
 
   1. Finally, the pull request will get merged or rejected.

diff --git a/website/docs/apiDefinition.json → docs/apiDefinition.json b/website/docs/apiDefinition.json → docs/apiDefinition.json
diff --git a/website/docs/cf-api-v2-usage.md → docs/cf-api-v2-usage.md b/website/docs/cf-api-v2-usage.md → docs/cf-api-v2-usage.md
diff --git a/website/docs/cf-api-v3.md → docs/cf-api-v3.md b/website/docs/cf-api-v3.md → docs/cf-api-v3.md
diff --git a/website/docs/cf-entity-scaling.md → docs/cf-entity-scaling.md b/website/docs/cf-entity-scaling.md → docs/cf-entity-scaling.md
diff --git a/docs/index.html b/docs/index.html
diff --git a/...ocs/guides/contribution/issue_template.md → docs/issue_template.md b/...ocs/guides/contribution/issue_template.md → docs/issue_template.md
diff --git a/website/docs/planning/angular.md → docs/planning/angular.md b/website/docs/planning/angular.md → docs/planning/angular.md
diff --git a/website/docs/planning/cf-user-management.md → docs/planning/cf-user-management.md b/website/docs/planning/cf-user-management.md → docs/planning/cf-user-management.md
diff --git a/website/docs/planning/metrics.md → docs/planning/metrics.md b/website/docs/planning/metrics.md → docs/planning/metrics.md
diff --git a/website/docs/planning/services.md → docs/planning/services.md b/website/docs/planning/services.md → docs/planning/services.md
diff --git a/...des/contribution/pull_request_template.md → docs/pull_request_template.md b/...des/contribution/pull_request_template.md → docs/pull_request_template.md
diff --git a/website/README.md b/website/README.md
@@ -23,7 +23,7 @@ This command starts a local development server and open up a browser window. Mos
 ### Build
 
 ```
-$ npm build
+$ ./deploy.sh -b
 ```
 
 This command generates static content into the `build` directory and can be served using any static contents hosting service.
@@ -33,5 +33,8 @@ This command generates static content into the `build` directory and can be serv
 We use GitHub pages - this command is a convenient way to build the website and push to the `gh-pages` branch.
 
 ```
-$ GIT_USER=<Your GitHub username> USE_SSH=true npm deploy
+$ ./deploy.sh
 ```
+
+
+> Note: The website is deployed to the GitHub Repository `cf-stratos/wesbite` which hosts https://stratos.app
diff --git a/website/deploy.sh b/website/deploy.sh
@@ -23,10 +23,44 @@ EOF
 
 # Concatentate the helm chart readme file
 tail -n +2 ${DIR}/../deploy/kubernetes/console/README.md >> ./docs/deploy/kubernetes/install.md
-npm run build
 
+# License file
+
+cat << EOF > ./docs/license.md
+---
+id: license
+title: License
+sidebar_label: License
+---
+
+Stratos is licensed under the Apache 2.0 Software License, shown below:
+
+\`\`\`
+EOF
+
+cat ${DIR}/../LICENSE >> ./docs/license.md
+echo "\`\`\`" >> ./docs/license.md
+
+# Contributing
+
+cat << EOF > ./docs/developer/contributing.md
+---
+title: Contributing
+sidebar_label: Contributing
+---
+
+EOF
+
+tail -n +2 ${DIR}/../CONTRIBUTING.md >> ./docs/developer/contributing.md
+
+# Copy and generate files only
+if [ "$ARG" == "-g" ]; then
+  exit 0
+fi
+
+npm run build
 
-# Build only
+# Generate and build only
 if [ "$ARG" == "-b" ]; then
   exit 0
 fi

diff --git a/website/docs/guides/metrics/bosh-metrics.md → website/docs/advanced/bosh-metrics.md b/website/docs/guides/metrics/bosh-metrics.md → website/docs/advanced/bosh-metrics.md
@@ -1,4 +1,7 @@
-# Connecting Prometheus-boshrelease to Stratos
+---
+title: Connecting Prometheus-boshrelease to Stratos
+sidebar_label: Connecting Prometheus-boshrelease
+---
 
 Stratos can show some metrics stored in Prometheus.
 

diff --git a/website/docs/advanced/invite-user-guide.md b/website/docs/advanced/invite-user-guide.md
@@ -42,7 +42,7 @@ In the above example the client id is `stratos-invite` and client secret is `pas
 
 Alternatively, you can use an existing UAA Client, if one is already available with the appropriate scopes.
 
-> Note: You will need the Client ID and Client Secret used above when enabling User Invite support in the Stratos UI
+> Note: You will need the Client ID and Client Secret used above when enabling User Invite support in Stratos
 
 ## Configuring SMTP Server details and (optionally) modifying Email Templates
 

diff --git a/website/docs/developer/contributing.md b/website/docs/developer/contributing.md
@@ -0,0 +1,162 @@
+---
+title: Contributing
+sidebar_label: Contributing
+---
+
+
+Stratos is an open project and welcomes contributions. These guidelines are provided to help you understand how the project works and to make contributing smooth and fun for everybody involved.
+
+There are two main forms of contribution: reporting issues and performing code changes.
+
+## Reporting Issues
+
+If you find a problem with Stratos, report it using [GitHub issues](https://github.com/cloudfoundry/stratos/issues/new).
+
+Before reporting a new issue, please take a moment to check whether it has already been reported
+[here](https://github.com/cloudfoundry/stratos/issues). If this is the case, please:
+
+- Read all the comments to confirm that it's the same issue you're having.
+- Refrain from adding "same thing here" or "+1" comments. Just hit the
+  "subscribe" button to get notifications for this issue.
+- Add a comment only if you can provide helpful information that has not been
+  provided in the discussion yet.
+
+When creating a new issue, make sure you include:
+
+1. As much detail as possible about your setup/environment
+1. Steps to reproduce the issue/bug
+1. What you expected to happen
+1. What happened instead
+
+This information will help to determine the cause and prepare a fix as fast as possible.
+
+## Code Changes
+
+Code contributions come in various forms and sizes, from simple bug fixes to implementation
+of new features. Before making any non-trivial change, get in touch with the Stratos developers first. This can prevent wasted effort later.
+
+To send your code change, use GitHub pull requests. The workflow is as follows:
+
+  1. Fork the project.
+
+  1. Create a branch based on `master`.
+
+  1. Implement your change, including tests and documentation.
+
+  1. Run tests to make sure your change didn't break anything.
+
+  1. Publish the branch and create a pull request.
+
+  1. Stratos developers will review your change and possibly point out issues.
+     Adapt the code under their guidance until all issues are resolved.
+
+  1. Finally, the pull request will get merged or rejected.
+
+See also [GitHub's guide on contributing](https://help.github.com/articles/fork-a-repo).
+
+If you want to do multiple unrelated changes, use separate branches and pull
+requests.
+
+### Commits
+
+Each commit in the pull request should do only one thing, which is clearly
+described by its commit message. Especially avoid mixing formatting changes and
+functional changes into one commit. When writing commit messages, adhere to
+[widely used
+conventions](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
+
+When the commit fixes a bug, put a message in the body of the commit message
+pointing to the number of the issue (e.g. "Fixes #123").
+
+### Pull requests and branches
+
+All work happens in branches. The master branch is only used as the target for pull
+requests.
+
+During code review you often need to update pull requests. Usually you do that
+by pushing additional commits.
+
+In some cases where the commit history of a pull request gets too cumbersome to
+review or you need bigger changes in the way you approach a problem which needs
+changing of commits you already did it's more practical to create a new pull
+request. This new pull request often will contain squashed versions of the
+previous pull request. Use that to clarify the changes contained in a pull
+request and to make review easier.
+
+When you replace a pull request by another one, add a message in the
+description of the new pull request on GitHub referencing the pull request it
+replaces (e.g. "Supersedes #123").
+
+Never force push commits. This changes history, can lead to data loss, and
+causes trouble for people who have checked out the changes which are overwritten
+by a force push. Don't waste time with thinking about if the force push in this
+one particular case would be ok, just don't do it.
+
+### Check for assigned people
+
+We use Github Issues for submitting known issues (e.g. bugs, features,
+etc.). Some issues will have someone assigned, meaning that there's already
+someone that takes responsibility for fixing the issue. This is not done to
+discourage contributions, rather to not step in the work that has already been
+done by the assignee. If you want to work on a known issue with someone already
+assigned to it, please contact the assignee first (e.g. by
+mentioning the assignee in a new comment on the specific issue). This way you
+can contribute with ideas, or even with code if the assignee decides that you
+can step in.
+
+If you plan to work on a non assigned issue, please add a comment on the issue
+to prevent duplicated work.
+
+### Sign your work
+
+The sign-off is a simple line at the end of the explanation for the change. Your
+signature certifies that you wrote the change or otherwise have the right to pass
+it on as an open-source change. The rules are pretty simple: if you can certify
+the below (from [developercertificate.org](http://developercertificate.org/)):
+
+```
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+660 York Street, Suite 102,
+San Francisco, CA 94110 USA
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.
+```
+
+Then you just add a line to each git commit message:
+
+    Signed-off-by: Joe Smith <joe.smith@email.com>
+
+Use your real name (sorry, no pseudonyms or anonymous contributions.)
+
+If you set your `user.name` and `user.email` git configs, you can sign your
+commit automatically with `git commit -s`.
diff --git a/.../docs/guides/customization/customizing.md → website/docs/extensions/customizing.md b/.../docs/guides/customization/customizing.md → website/docs/extensions/customizing.md
@@ -4,37 +4,8 @@ title: Customizing Stratos
 sidebar_label: Customizing Stratos 
 ---
 
-Stratos provides a mechanism for customization - the following customizations are currently supported:
-
-- Changing the theme colors
-- Changing certain image assets (favorite icon, login background and logo)
-- Overriding styles
-- Adding new functionality
-- Changing the initial loading indicator
-
-# Migrating to Stratos V4 Customization
-In V4 there are breaking customization changes. These changes allow a much improved approach to extensions by opening the door to npm style plugins.
-To aid in migrating we've provided these instructions.
-
-1) Before updating to the latest code...
-    1) Run `npm run customize-reset` to remove all previously created sym links.
-    2) Read through the customization documentation below to get a better understanding of the new process.
-1) Update your codebase with the desired v4 code.
-1) Run `npm install` (only required first time, this will ensure you have the required version of Angular).
-1) Change directory to `./build/tools/v4-migration` and run the migration script `./migrate.sh`.
-    - This will copy your customizations from `custom-src` to a new Angular package `src/frontend/packages/custom_extensions`.
-1) Check that the new package exports your custom module and if applicable your custom-routing module.
-    - The migrate script should do this in `src/frontend/packages/custom_extensions/src/public-api.ts`.
-1) Check that your ts config file defines the public api file.
-    - `src/tsconfig.json` file's `compilerOptions/paths` section should contain something like `"@custom/extensions": ["frontend/packages/custom_extensions/src/public-api.ts"]`.
-1) Check that your new package's package.json defines your custom module and if application custom-routing module.
-    - See `src/frontend/packages/suse_extensions/package.json` file's `stratos` section.
-    - Note your `routingModule` entry label should not have a preceding `_`.
-1) Build Stratos in your usual way, for instance `npm run build`.
-    - It could be that this fails due to TypeScript import issues, if so go through these and fix.
-    - During build time the custom packages will be discovered and output, see section starting `Building with these extensions`. These should contain the modules your require.
-1) Run Stratos your usual way. Ensure you can navigate to all your custom parts.
-1) Once you are happy everything works as intended remove the old `./custom-src` directory and commit you changes.
+
+> This document is out of date and is in the process of being refreshed.
 
 ## Approach
 
@@ -150,7 +121,7 @@ When you perform an `npm install` or explicitly run `npm run customize`, the cus
 
 Within the `custom-src/frontend/app/custom` folder you must create a module in the file `custom.module.ts` named `CustomModule` - this will be imported into the Stratos application and is the mechanism by which you can add custom code to the front-end.
 
-We currently expose the following extension points in the Stratos UI:
+We currently expose the following extension points in Stratos:
 
 - Changing the component to use for the login screen
 - Adding new items to the side navigation menu

diff --git a/website/docs/extensions/theming.md b/website/docs/extensions/theming.md
@@ -2,4 +2,13 @@
 title: Theming Stratos
 sidebar_label: Theming Stratos
 ---
-This document is in progress
+This document is in progress
+
+Stratos provides a mechanism for customizing the theme, including:
+
+- Changing the theme colors
+- Changing image assets (favorite icon, login background and logo)
+- Overriding styles
+- Changing the initial loading indicator
+
+The easiest way to create a theme is to create a folder in the `src/frontend/packages` folder.
diff --git a/website/docs/extensions/v4-migration.md b/website/docs/extensions/v4-migration.md
@@ -0,0 +1,30 @@
+---
+title: Migrating to V4
+sidebar_label:  Migrating to V4
+---
+
+In version 4 of Stratos there are breaking customization changes from previous versions.
+
+These changes allow a much improved approach to extensions by opening the door to npm style plugins.
+
+To aid in migrating we've provided these instructions.
+
+1. Before updating to the latest code...
+    - Run `npm run customize-reset` to remove all previously created sym links.
+    - Read through the customization documentation below to get a better understanding of the new process.
+1. Update your codebase with the desired v4 code.
+1. Run `npm install` (only required first time, this will ensure you have the required version of Angular).
+1. Change directory to `./build/tools/v4-migration` and run the migration script `./migrate.sh`.
+    - This will copy your customizations from `custom-src` to a new Angular package `src/frontend/packages/custom_extensions`.
+1. Check that the new package exports your custom module and if applicable your custom-routing module.
+    - The migrate script should do this in `src/frontend/packages/custom_extensions/src/public-api.ts`.
+1. Check that your ts config file defines the public api file.
+    - `src/tsconfig.json` file's `compilerOptions/paths` section should contain something like `"@custom/extensions": ["frontend/packages/custom_extensions/src/public-api.ts"]`.
+1. Check that your new package's package.json defines your custom module and if application custom-routing module.
+    - See `src/frontend/packages/suse_extensions/package.json` file's `stratos` section.
+    - Note your `routingModule` entry label should not have a preceding `_`.
+1. Build Stratos in your usual way, for instance `npm run build`.
+    - It could be that this fails due to TypeScript import issues, if so go through these and fix.
+    - During build time the custom packages will be discovered and output, see section starting `Building with these extensions`. These should contain the modules your require.
+1. Run Stratos your usual way. Ensure you can navigate to all your custom parts.
+1. Once you are happy everything works as intended remove the old `./custom-src` directory and commit you changes.