Docs changes to reflect this is not limited to Travis CI.

Author: kabalin

README.md

@@ -4,9 +4,11 @@
 [![Total Downloads](https://poser.pugx.org/moodlehq/moodle-plugin-ci/downloads)](//packagist.org/packages/moodlehq/moodle-plugin-ci)
 [![License](https://poser.pugx.org/moodlehq/moodle-plugin-ci/license)](//packagist.org/packages/moodlehq/moodle-plugin-ci)
 
-The goal of this project is to facilitate the running of tests and code analysis against a Moodle plugin in
-[Travis CI](https://travis-ci.com).  All of these tests and tools are run everytime a change is pushed to a GitHub
-branch or pull request.
+The goal of this project is to facilitate the running of tests and code
+analysis against a Moodle plugin in CI tools, such as [Travis
+CI](https://travis-ci.com) or [GitHub
+Actions](https://docs.github.com/en/actions).  All of these tests and tools
+are run everytime a change is pushed to a GitHub branch or pull request.
 
 * [Getting started](https://moodlehq.github.io/moodle-plugin-ci/)
 * [Help topics](https://moodlehq.github.io/moodle-plugin-ci/Help.html)

docs/CHANGELOG.md

@@ -12,7 +12,7 @@ The format of this change log follows the advice given at [Keep a CHANGELOG](htt
 ### Fixed
 - `moodle-plugin-ci grunt` now only runs against the `yui/src` directory when configuring the YUI task.
   This resolves an issue where an "Unable to find local grunt" message was reported when code was structured in a legacy
-  format. See #46 for more details.
+  format. See [#46](https://github.com/moodlehq/moodle-plugin-ci/issues/46) for more details.
 
 ### Changed
 - `moodle-plugin-ci phpunit` when coverage report is included, phpdbg is called with ignore memory limits param
@@ -21,7 +21,7 @@ The format of this change log follows the advice given at [Keep a CHANGELOG](htt
 
 ### Added
 - Detect existence of legacy php-webdriver, and use a different Firefox image when it is in use.
-- GitHub Actions use manual and example.
+- Add [manual](https://github.com/moodlehq/moodle-plugin-ci/blob/master/docs/index.md) and [example](https://github.com/moodlehq/moodle-plugin-ci/blob/master/docs/GHAFileExplained.md) on using GitHub Actions as CI tool.
 
 ## [3.0.3] - 2020-10-16
 ### Changed

docs/GHAFileExplained.md

@@ -8,8 +8,8 @@ Below is the
 file with comments added to explain what each section is doing. For additional
 information please refer to [workflow syntax reference](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions).
 
-If you are familiar with Travis, this should be strightforward to understand
-the syntax, you may find this [migration
+If you are familiar with Travis, it should be straightforward to understand
+the new syntax, also you may find this [migration
 manual](https://docs.github.com/en/actions/learn-github-actions/migrating-from-travis-ci-to-github-actions)
 useful.
 
@@ -52,6 +52,9 @@ jobs:
     # build will be created. For example below 6 builds will be created in
     # total (7.2-pgsql, 7.2-mariadb, 7.3-pgsql, 7.3-mariadb, etc.). If we add
     # another branch, total number of builds will become 12.
+    # If you need to use PHP 7.0 and run phpunit coverage test, make sure you are
+    # using ubuntu-16.04 virtual environment in this case to have phpdbg or
+    # this version in the system.
     strategy:
       fail-fast: false
       matrix:

docs/Help.md

@@ -18,6 +18,75 @@ changed.  Also a good place to look for new goodies.
 * [Generating code coverage](CodeCoverage.md): how to generate code coverage of your plugin.
 * [CLI commands and options](CLI.md): the available `moodle-plugin-ci` commands and their options.
 
+## Test steps quick start
+
+Below is short reference to steps you may find useful to optimise set of test steps you want to
+inclide in the CI scenario. For detailed information, see [CLI commands and options](CLI.md) manual.
+
+**moodle-plugin-ci phplint**
+
+This step lints your PHP files to check for syntax errors.
+
+**moodle-plugin-ci phpcpd**
+
+This step runs the PHP Copy/Paste Detector on your plugin. This helps to find
+code duplication.
+
+**moodle-plugin-ci phpmd**
+
+This step runs the PHP Mess Detector on your plugin. This helps to find
+potential problems with your code which can result in refactoring
+opportunities.
+
+**moodle-plugin-ci codechecker**
+
+This step runs the Moodle Code Checker to make sure that your
+plugin conforms to the Moodle coding standards.  It is highly recommended that
+you keep this step.  To fail on warnings use `--max-warnings 0`
+
+**moodle-plugin-ci phpdoc**
+
+This step runs Moodle PHPDoc checker on your plugin.
+
+**moodle-plugin-ci validate**
+
+This step runs some light validation on the plugin file structure
+and code.  Validation can be plugin specific.
+
+**moodle-plugin-ci savepoints**
+
+This step validates your plugin's upgrade steps.
+
+**moodle-plugin-ci mustache**
+
+This step validates the HTML and Javascript in your Mustache templates.
+
+**moodle-plugin-ci grunt**
+
+This step runs Grunt tasks on the plugin.  By default, it tries to run tasks
+relevant to your plugin and Moodle version, but you can run specific tasks by
+passing them as options, e.g.: `moodle-plugin-ci grunt -t task1 -t task2` To
+fail on eslint warnings use `--max-lint-warnings 0`
+
+**moodle-plugin-ci phpunit**
+
+This step runs the PHPUnit tests of your plugin.  If your plugin has
+PHPUnit tests, then it is highly recommended that you keep this step.
+
+**moodle-plugin-ci behat**
+
+This step runs the Behat tests of your plugin.  If your plugin has
+Behat tests, then it is highly recommended that you keep this step.
+There are few important options that you may want to use:
+- The auto rerun option allows you to rerun failures X number of times,
+  default is 2, EG usage: `--auto-rerun 3`
+- The dump option allows you to print the failure HTML to the console,
+  handy for debugging, e.g. usage: `--dump`
+- The suite option allows you to set the theme to use for behat test. If
+  not specified, the default theme is used, e.g. usage: `--suite boost`
+- The profile option allows you to set the browser driver to use,
+  default is Firefox. If you need Chrome, set `--profile chrome`.
+
 ## Upgrade guides
 
 * [Upgrading to Version 3](UPGRADE-3.0.md)

docs/index.md

@@ -3,14 +3,21 @@ layout: page
 title: Introduction
 ---
 
-The goal of this project is to facilitate the running of tests and code analysis against a Moodle plugin in
-[Travis CI](https://travis-ci.com).  All of these tests and tools are run everytime a change is pushed to a GitHub
-branch or pull request.
+The goal of this project is to facilitate the running of tests and code
+analysis against a Moodle plugin in CI tool of your choice. All of these tests
+and tools are run everytime a change is pushed to a GitHub branch or pull
+request.
+
+We currently provide user manual how to use it with [Travis
+CI](https://travis-ci.com) and [GitHub
+Actions](https://docs.github.com/en/actions), if you are using
+`moodle-plugin-ci` with other CI services please do share your setup examples
+by creating a ticket.
 
 Why would you want to do this?  It saves you from having to remember to setup and run PHPUnit, Behat, code checker, etc
 every single time you make a change.  If you have enough test coverage, it also makes accepting pull requests painless
-because you can be more confident that the change wont break anything.  There are many more advantages to using a
-service like Travis CI, like being able to test your code against multiple databases, multiple PHP versions, etc.
+because you can be more confident that the change wont break anything.  There are many more advantages to use CI
+tools, like being able to test your code against multiple databases, multiple PHP versions, etc.
 
 This project supports the following testing frameworks and code analysis tools:
 * [PHPUnit](https://phpunit.de)
@@ -76,12 +83,13 @@ pull request, GitHub will run a build to make sure nothing broke.
 
 ### Getting more of CI
 
-Congratulations, you are running CI tests on your plugin!  Next steps on your continuous build journey include:
+Next steps on your continuous build journey may include:
 
 * Reviewing the [help documentation](Help.md) to further improve and customize your build.
 * Resolve any build errors you may currently have. Get to that ever rewarding Green Build status.
-* Show off your build status by adding the badge to your plugin's README file.
+* Show off your build status by adding the build status badge to your plugin's README file.
 * Write new tests to increase your code coverage.
+* Contribute to this repo if you have improvement idea or found an issue.
 * Enjoy your favorite beverage because you no longer have to waste time manually testing your plugin!
 
 ## Upgrading