Add testing of deployed Moodle site to the CI process

[SorraTheOrc]

In #72 we are adding a test infrastructure to this repo that will allow us to validate contributions to this repo. This solution will do some syntax and best practice checking of the contributions and it will test that a deployment of the template works from an ARM perspective. However, it does not test that the Moodle is working and available.

Once this initiual work (#72) is complete we need to extend it to allow a deeper level of testing. For example:

1. deploy a configuration of Moodle
2. tests the correct installation of selected features in that configuration
3. runs the load testing against it and report
   [repeat for x different configurations]

Lets start with a focus on 1)

Our documentation is written to allow it to be used as a test script. Installing SimDem and running simdem -p . test Deploy.md in the docs folder will test the deployment of Moodle (item 1 above).

There is an example of using SimDem in Circle CI at https://github.com/Azure/acs-demos/blob/master/.circleci/config.yml

This is a good starting point, but happy to discuss further here once we start looking at this in detail.

[SorraTheOrc]

For clarity step 3, the load testing step, should only occur on demand or during preparation of a release. This is an expensive and time consuming set of tests.

[hosungsmsft]

Rephrased this issue title for v1.5.1, where we focus on no. 2 of this issue (1 is done now). 3 (load testing running) is not scoped in here.

[hosungsmsft]

FYI, all the necessary information for testing the deployed site is available from az group deployment show -g $AZURE_RESOURCE_GROUP -n azuredeploy --query properties.outputs. You can add the next-level field name in the --query properties.outputs to get a specific output, or simply use jq to extract needed information from the JSON output.

[roperto]

Hi @hosungsmsft -- I've noticed you added "CI only master branch". Is there a reason behind that?

I think it would be nice to have it for all branches. It is common, for example, to create a feature branch and do all dev work on that before merging back into master, and it would be nice to have the CI running on those branches too.

See: dcceea9#diff-354f30a63fb0907d4ad57269548329e3R4

What do you think?

Cheers

[hosungsmsft]

@roperto -- Thanks for your question. My reasoning behind that restriction was that the full CI that includes the test deployment might be unnecessarily costly for non-master branches (time-wise and Azure cost-wise). I'd be totally fine if the linting part of the CI is run on every branch, and I suppose that can be programmatically controlled using some env var? What do you think? Thanks!

[roperto]

@hosungsmsft -- That is a good point, I created #90 to separate it from this thread and I will continue working on this issue. Thank you for the feedback.

[hosungsmsft]

Fixed in #91