Move non-code files to cht-docs and support-scripts repos

medic#7413

.github/workflows/build.yml

@@ -141,7 +141,7 @@ jobs:
       run: |
         echo "COUCH_URL=$COUCH_URL HORTI_BUILDS_SERVER=$MARKET_URL_READ/$BUILDS_SERVER"
         docker-compose -f scripts/ci/horti-compose.yml up -d 
-        sh scripts/e2e/wait_for_response_code.sh 5988 200 api
+        sh scripts/wait_for_response_code.sh 5988 200 api
     # Restarting horti to install on a different builds server.
     # Used for installing the current release then installing the beta. 
     - name: Install Latest Build After Installing Latest In Previous Startup
@@ -150,7 +150,7 @@ jobs:
         docker stop horti
         docker logs horti > tests/logs/horti_before_recreate_container.log 2>&1
         INSTALL_LATEST=yes docker-compose -f scripts/ci/horti-compose.yml up -d 
-        sh scripts/e2e/wait_for_response_code.sh 5988 200 api
+        sh scripts/wait_for_response_code.sh 5988 200 api
       if: startsWith(github.ref, 'refs/tags/')
     - name: Test it!
       run: node --stack_size=10000 `which grunt` ${{ matrix.grunt-cmd }}

CODE_OF_CONDUCT.md

@@ -1,54 +1 @@
-# Code of Conduct
-
-All maintainers and contributors in this community are required to act according to the following Code of Conduct. These guidelines help steer our interactions and help us provide and ensure a safe environment for everyone.
-
-## Our Standards
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
-* The use of sexualized language or imagery and unwelcome sexual attention or
- advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
- address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
- professional setting
-
-## Our Responsibilities
-
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the community manager at [email protected]. All
-complaints will be reviewed and investigated and will result in a response that
-is deemed necessary and appropriate to the circumstances. The project team is
-obligated to maintain confidentiality with regard to the reporter of an incident.
-Further details of specific enforcement policies may be posted separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-## Attribution
-
-This Code of Conduct is adapted from the Contributor Covenant, [version 1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html). For answers to common questions about this code of conduct, see https://www.contributor-covenant.org/faq
+Read about how to contribute on the [documentation site](https://docs.communityhealthtoolkit.org/contribute/code-of-conduct).

CONTRIBUTING.md

@@ -1,103 +1 @@
-# Contributing
-[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](http://makeapullrequest.com)
-
-The Core Framework of the Community Health Toolkit is powered by people like you. Your contributions help us create open source technology for a new model of healthcare that reaches everyone.
-
-## [Ways to contribute](#ways-to-contribute)
-  - [First time contributor? Start here!](#first-time-contributor)
-  - [Review or add a translation](#translations)
-  - [Submitting code](#submitting-code)
-  - [Improving our documentation](#improving-our-documentation)
-  - [Disclosing vulnerabilities](#disclosing-vulnerabilities)
-  - [Code of conduct](#code-of-conduct)
-
-
-## Communication
-We recommend you raise an issue on Github or start a conversation on our [Community Forum](https://forum.communityhealthtoolkit.org) about the change you want to make before you start on code. Our Community Forum is especially helpful if you are a new contributor or find yourself unsure how to move forward with an issue.
-
-## Ways to contribute
-
-### First time contributor?
-Issues labeled [help wanted](https://github.com/medic/cht-core/labels/Help%20wanted) are a great place to start. Looking for other ways to help? You can also:
-* Improve our [documentation](#improving-our-documentation)
-* Review or add a [translation](#translations)
-* Find and mark duplicate issues
-* Try to reproduce issues and help with troubleshooting
-* Or [share a new idea or question](https://forum.communityhealthtoolkit.org) with us!
-* **Working on your first Pull Request?** Check out [How to Contribute to an Open Source Project on GitHub](https://egghead.io/lessons/javascript-introduction-to-github)
-
-### Submitting code
-**Note:** We recommend you raise an issue on Github or start a conversation on our [Community Forum](https://forum.communityhealthtoolkit.org) about the change you want to make before you start on code.
-
-1. Read our [Development Workflow](https://docs.communityhealthtoolkit.org/contribute/code/workflow/) to understand how we work, and review our [Code Style Guide](https://docs.communityhealthtoolkit.org/contribute/code/style-guide/) before you begin.
-2. Before you submit a pull request, please make sure your contribution passes all tests. Test failures need to be addressed before we can merge your contribution.
-3. Provide detail about the issue you are solving in the pull request description. Note: If your pull request addresses a specific issue, please reference it using medic/<repo>#<issue number>
-4. Our CI will automatically schedule a build; monitor the build to ensure it passes.
-5. Your PR will be reviewed by one of the repository's maintainers. Most PRs have at least one change requested before they're merged so don't be offended if your change doesn't get accepted on the first try!
-
-### Improving our documentation
-
-**Note:** [cht-docs](https://github.com/medic/cht-docs) does not involve release management and acceptance testing. Help us maintain the quality of our documentation by submitting a pull request (PR) with any suggested changes.
-
-Is our documentation up to date? Have we covered everything we should? Could our wording be improved? Read our [Documentation Style Guide](https://docs.communityhealthtoolkit.org/contribute/docs/style-guide/) then open a pull request with your suggested changes or additions.
-Want to talk about Documentation generally? Join our [Community Forum](https://forum.communityhealthtoolkit.org)!
-
-### Translations
-
-If you are a translator but not a developer, we understand that you may need extra help to follow the [process of translating](https://docs.communityhealthtoolkit.org/apps/reference/translations/) software for the first time. If that is the case, please open an issue on the GitHub repo or start a topic on the community forum.
-
-### Disclosing vulnerabilities
-
-We take the security of our systems seriously, and we value the security community. The disclosure of security vulnerabilities helps us ensure the security and privacy of our users.
-
-#### Guidelines
-
-We require that all researchers:
-
-- Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction of data during security testing;
-- Refrain from using any in-scope compromise as a platform to probe or conduct additional research, on any other system, regardless of scope;
-- Perform research only within the scope set out below;
-- Use the identified communication channels to report vulnerability information to us; and
-- Keep information about any vulnerabilities you've discovered confidential between yourself and Medic until all production systems have been patched.
-
-If you follow these guidelines when reporting an issue to us, we commit to:
-
-- Not pursue or support any legal action related to your research;
-- Work with you to understand and resolve the issue quickly (including an initial confirmation of your report within 72 hours of submission);
-- Recognize your contribution on our Security Researcher Hall of Fame, if you are the first to report the issue and we make a code or configuration change based on the issue.
-
-#### Scope
-
-- https://alpha.dev.medicmobile.org
-
-#### Out of scope
-
-Any services hosted by 3rd party providers and any and all other services hosted on or beneath the medicmobile.org and hopephones.org domains are excluded from scope.
-
-In the interest of the safety of our users, staff, the Internet at large and you as a security researcher, the following test types are excluded from scope:
-
-- Findings from physical testing such as office access (e.g. open doors, tailgating)
-- Findings derived primarily from social engineering (e.g. phishing, vishing)
-- Findings from applications or systems not listed in the ‘Scope' section
-- UI and UX bugs and spelling mistakes
-- Network level Denial of Service (DoS/DDoS) vulnerabilities
-
-Things we do not want to receive:
-
-- Personally identifiable information (PII)
-- Any exploits or proofs-of-concept in binary format (e.g. ELF)
-
-#### How to report a security vulnerability?
-
-If you believe you've found a security vulnerability in one of our products or platforms please send it to us by emailing [email protected]. Please include the following details with your report:
-
-- Description of the location and potential impact of the vulnerability;
-- A detailed description of the steps required to reproduce the vulnerability (proof of concept source code, screenshots, and compressed screen captures are all helpful to us); and
-- Your name/handle and a link for recognition in our Hall of Fame.
-
-### Code of Conduct
-
-All maintainers and contributors are required to act according to our [Code of Conduct](https://github.com/medic/medic/blob/master/CODE_OF_CONDUCT.md). Thank you for your help building a positive community and a safe environment for everyone.
-
-#### License
-The software is provided under AGPL-3.0. Contributions to this project are accepted under the same license.
+Read about how to contribute on the [documentation site](https://docs.communityhealthtoolkit.org/contribute/).

Changes.md

@@ -1,3 +1,3 @@
-# Medic Release Notes
+# CHT Core release notes
 
-Release notes are now published in the [release-notes](https://github.com/medic/cht-core/tree/master/release-notes) directory.
+Release notes for CHT Core have been moved to the [CHT documentation site](https://docs.communityhealthtoolkit.org/core/releases/).

Gruntfile.js

@@ -401,7 +401,7 @@ module.exports = function(grunt) {
       'setup-test-database': {
         cmd: [
           `docker run -d -p 4984:5984 -p 4986:5986 --rm --name e2e-couchdb --mount type=tmpfs,destination=/opt/couchdb/data couchdb:2`,
-          'sh scripts/e2e/wait_for_response_code.sh 4984 200 couch',
+          'sh scripts/wait_for_response_code.sh 4984 200 couch',
           `curl 'http://localhost:4984/_cluster_setup' -H 'Content-Type: application/json' --data-binary '{"action":"enable_single_node","username":"admin","password":"pass","bind_address":"0.0.0.0","port":5984,"singlenode":true}'`,
           'COUCH_URL=http://admin:pass@localhost:4984/medic COUCH_NODE_NAME=nonode@nohost grunt secure-couchdb', // yo dawg, I heard you like grunt...
           // Useful for debugging etc, as it allows you to use Fauxton easily
@@ -410,7 +410,7 @@ module.exports = function(grunt) {
       },
       'wait_for_api_down': {
         cmd: [
-          'sh scripts/e2e/wait_for_response_code.sh 4988 000 api',
+          'sh scripts/wait_for_response_code.sh 4988 000 api',
         ].join('&& '),
         exitCodes: [0, 1] // 1 if e2e-couchdb doesn't exist, which is fine
       },
@@ -421,7 +421,7 @@ module.exports = function(grunt) {
         exitCodes: [0, 1] // 1 if e2e-couchdb doesn't exist, which is fine
       },
       'e2e-servers': {
-        cmd: `${BUILD_NUMBER ? 'echo running in CI' :'node ./scripts/e2e/e2e-servers.js &'}`
+        cmd: `${BUILD_NUMBER ? 'echo running in CI' :'node ./tests/scripts/e2e-servers.js &'}`
       },
       bundlesize: {
         cmd: 'node ./node_modules/bundlesize/index.js',
@@ -454,7 +454,7 @@ module.exports = function(grunt) {
       },
       'start-webdriver-ci': {
         cmd:
-          'scripts/e2e/start_webdriver.sh'
+          'tests/scripts/start_webdriver.sh'
       },
       'check-env-vars':
         'if [ -z $COUCH_URL ] || [ -z $COUCH_NODE_NAME ]; then ' +

TESTING.md

@@ -88,7 +88,7 @@ To run just a single test file in WebdriverIO, update the `specs` config in [tes
 1. Paste those files into a directory called .vscode within your cht-core repo. 
 1. Click the debug icon on the left tool bar.
 1. Select launch e2e.
-1. This will now run as if you ran the command `grunt e2e-deploy` and start the `scripts/e2e/e2e-servers` script. Then launch protractor to debug the test(s). 
+1. This will now run as if you ran the command `grunt e2e-deploy` and start the `tests/scripts/e2e-servers` script. Then launch protractor to debug the test(s). 
 
 ##### Debugging a single test by using the "grep" feature.