From fad576895aa507b3d6853ae2da08b4ea31396b48 Mon Sep 17 00:00:00 2001
From: donal <donalspring@gmail.com>
Date: Wed, 09 May 2018 17:58:31 +0200
Subject: [PATCH] remove shell and confusing npm i

---
 exercises/5-non-functionals-strike-back/README.md      |   20 ++-
 exercises/6-return-of-the-app-monitoring/README.md     |   10 +
 exercises/2-attack-of-the-pipelines/README.md          |   19 ++
 exercises/3-revenge-of-the-automated-testing/README.md |  126 +++++++++++++-------
 exercises/4-an-enslaved-hope/README.md                 |  138 ++++++++++++++++-------
 5 files changed, 216 insertions(+), 97 deletions(-)

diff --git a/exercises/2-attack-of-the-pipelines/README.md b/exercises/2-attack-of-the-pipelines/README.md
index a4fc167..bfe136c 100644
--- a/exercises/2-attack-of-the-pipelines/README.md
+++ b/exercises/2-attack-of-the-pipelines/README.md
@@ -81,12 +81,19 @@
 
 2. Git clone the `todolist-fe` project to somewhere sensible and checkout the `develop` branch.
 ```bash
+cd ~/innovation-labs
+```
+```bash
 git clone https://github.com/rht-labs/todolist-fe.git
+```
+```bash
 cd todolist-fe
-git checkout develop
 ```
 ```bash
 ./git-pull-all.sh
+```
+```bash
+git checkout develop
 ```
 
 2. Open up Gitlab and login. Create a new project (internal) in GitLab called `todolist-fe` to host your clone of the project and copy it's remote address. ![new-gitlab-proj](../images/exercise2/new-gitlab-proj.png)
@@ -186,12 +193,19 @@
 
 2. Now let's move on to the `todolist-api` and wire them together. As with the `todolist-fe` we need to clone the repo and add it to our GitLab in the cluster.
 ```bash
+cd ~/innovation-labs
+```
+```bash
 git clone https://github.com/rht-labs/todolist-api.git
+```
+```bash
 cd todolist-api
-git checkout develop
 ```
 ```bash
 ./git-pull-all.sh
+```
+```bash
+git checkout develop
 ```
 
 2. On GitLab; create a new project (internal) called `todolist-api` to host your clone of the project and copy it's remote address as you did for the previous repositories.
@@ -206,7 +220,6 @@
 
 2. Once pushed; explore the application. It is a NodeJS application with the Express.js framework and MongoDB for persistent storage. Same as before, the `package.json` defines most of the configuration etc. Install the dependencies
 ```bash
-# npm i === npm install
 npm i
 ```
 
diff --git a/exercises/3-revenge-of-the-automated-testing/README.md b/exercises/3-revenge-of-the-automated-testing/README.md
index 8eee1e8..c52716d 100644
--- a/exercises/3-revenge-of-the-automated-testing/README.md
+++ b/exercises/3-revenge-of-the-automated-testing/README.md
@@ -96,8 +96,10 @@
 
 2. Before linking our automated testing to the pipeline we'll first ensure the tests run locally. Change to the `todolist-fe` directory and run `test`.
 ```bash
-$ cd todolist-fe
-$ npm run test
+cd todolist-fe
+```
+```bash
+npm run test
 ```
 <p class="tip" > 
 `test` is an alias used that runs `vue-cli-service test` from the scripts object in `package.json`
@@ -111,8 +113,10 @@
 
 2. Repeat the same process for `todolist-api` and verify that all the tests run. If you have an ExpressJS server already running from previous exercise; you should kill it before running the tests. The `mocha` test suite will launch a dev server for running the tests. There are 2 Api test files: `todolist-api/server/api/todo/todo.spec.js` & `todolist-api/server/mocks/mock-routes.spec.js` for our API and the Mocks server.
 ```bash
-$ cd todolist-api
-$ npm run test
+cd todolist-api
+```
+```bash
+npm run test
 ```
 
 2. Navigate to your instance of jenkins at `https://jenkins-<YOUR_NAME>-ci-cd.apps.somedomain.com/`. 
@@ -135,9 +139,13 @@
 
 2. Push this to Gitlab and run the build job.
 ```bash
-$ git add .
-$ git commit -m "TEST - failing build with tests"
-$ git push
+git add .
+```
+```bash
+git commit -m "TEST - failing build with tests"
+```
+```bash
+git push
 ```
 
 2. Rerun the `dev-todolist-fe-build` job. It should have failed and not run any other jobs. 
@@ -153,7 +161,7 @@
 
 2. We're now going to do the same for the api. However, in order to run our API tests in CI; we need there to be a MongoDB available for testing. In our `enablement-ci-cd` repo; checkout the mongo branch as shown below to bring in the template and params. The mongodb template we're using is the same as the one for our `todolist-fe` created in previous exercise.
 ```bash
-$ git checkout exercise3/mongodb params/mongodb templates/mongodb.yml
+git checkout exercise3/mongodb params/mongodb templates/mongodb.yml
 ```
 
 2. Open `enablement-ci-cd` in your favourite editor. Edit the `inventory/host_vars/ci-cd-tooling.yml` to include a new object for our mongodb  as shown below. This item can be added below the jenkins slave in the `ci-cd-builds` section.
@@ -169,14 +177,18 @@
 
 2. Git commit your updates to the inventory to git for traceability.
 ```bash
-$ git add .
-$ git commit -m "ADD - mongodb for use in the pipeline"
-$ git push
+git add .
+```
+```bash
+git commit -m "ADD - mongodb for use in the pipeline"
+```
+```bash
+git push
 ```
 
 2. Apply this change as done previously using ansible. The deployment can be validated by going to your `<YOUR_NAME>-ci-cd` namespace! 
 ```bash
-$ ansible-playbook apply.yml -e target=tools \
+ansible-playbook apply.yml -e target=tools \
   -i inventory/ \
   -e "filter_tags=mongodb"
 ```
@@ -197,9 +209,13 @@
 
 2. Push this to Gitlab and run the build job.
 ```bash
-$ git add .
-$ git commit -m "TEST - failing build with tests"
-$ git push
+git add .
+```
+```bash
+git commit -m "TEST - failing build with tests"
+```
+```bash
+git push
 ```
 
 2. If successful this will fail the build and not run the `bake` or `deploy` jobs! Undo your changes and move on to the next section.
@@ -215,12 +231,12 @@
 
 2. Let's start by checking our tests execute locally. On the terminal move to the `todolist-fe` folder. Our end to end tests are stored in `tests/e2e/specs/`. The vuejs cli uses nightwatch and comes pre-configured to run tests against Chrome. We have created some additional configuration in the root of the project `nightwatch.config.js` to run headless in CI mode on Jenkins.
 ```bash
-$ cd todolist-fe
+cd todolist-fe
 ```
 
 2. Run the tests locally by executing the following. This should start the dev server and run the test. You may see the browser pop up and close while tests execute.
 ```bash
-$ npm run e2e
+npm run e2e
 ```
 ![local-e2e](../images/exercise3/local-e2e.png)
 
@@ -270,8 +286,10 @@
 
 3.  Create a new branch in your `todolist-api` app for our feature and push it to the remote
 ```bash
-$ git checkout -b feature/important-flag
-$ git push -u origin feature/important-flag
+git checkout -b feature/important-flag
+```
+```bash
+git push -u origin feature/important-flag
 ```
 
 3.  Navigate to the `server/api/todo/todo.spec.js` file. This contains all of the existing todo list api tests. These are broken down into simple `describe("api definition", function(){})` blocks which is BDD speak for how the component being tested should behave. Inside of each `it("should do something ", function(){})` statements we use some snappy language to illustrate the expected behaviour of the test. For example a `GET` request of the api is described and tested for the return to be of type Array as follows.
@@ -304,7 +322,7 @@
 
 3. Before writing our test; let's first make sure all the existing tests are passing.
 ```bash
-$ npm run test
+npm run test
 ```
 
 3. With all the tests passing; let's add our new one. For ease of completing this exercise a template of a new test has been written at the very end of the file (just below the `  // Exercise 3 test case!` comment). A PUT request responds in our API with the data that it has just updated. So provided that MongoDB accepted the change, the API will respond with an object that has the `important` property on it. To write our test; edit the template test by completing the following:
@@ -337,7 +355,7 @@
 
 3.  Run your test. It should fail.
 ```bash
-$ npm run test
+npm run test
 ```
 ![fail-mocha](../images/exercise3/fail-mocha.png)
 
@@ -355,7 +373,7 @@
 
 3.  With your changes to the Database schema updated; re-run your tests.
 ```bash
-$ npm run test
+npm run test
 ```
 
 3.  Commit your code to the `feature/important-flag` branch and then merge onto the `develop` branch as follows
@@ -363,18 +381,27 @@
 NOTE - At this point in a residency we would peer review the code before pushing it to develop or master branch!
 </p>
 ```bash
-$ git add .
-$ git commit -m "ADD backend schema updates"
-$ git push
-# Now Update our develop branch to trigger a build!
-$ git checkout develop
-$ git merge feature/important-flag
-$ git push
+git add .
+```
+```bash
+git commit -m "ADD backend schema updates"
+```
+```bash
+git push
+```
+```bash
+git checkout develop
+```
+```bash
+git merge feature/important-flag
+```
+```bash
+git push
 ```
 
 3.  After pushing your changes; start back up the `todolist-api` app on a new terminal session
 ```bash
-$ npm run start
+npm run start
 ```
 
 #### 2b - Create todolist-fe tests
@@ -398,13 +425,15 @@
 
 3. Let's implement our feature by first creating a branch. Our new feature, important flag will behave in the same way as the `MARK_TODO_COMPLETED`. Create a new branch in your `todolist-fe` app for our feature and push it to the remote
 ```bash
-$ git checkout -b feature/important-flag
-$ git push -u origin feature/important-flag
+git checkout -b feature/important-flag
+```
+```bash
+git push -u origin feature/important-flag
 ```
 
 3. Let's get our tests running by executing a `--watch` on our tests. This will keep re-running our tests everytime there is a file change. It is hany to have this running in a new terminal session.
 ```bash
-$ npm run test -- --watch
+npm run test -- --watch
 ```
 
 3. All the tests should be passing when we begin. If `No tests found related to files changed since last commit` is on show; hit `a` on the terminal to re-run `all` tests.
@@ -494,7 +523,6 @@
 ```
 
 3. Let's connect the click button in the DOM to the Javascript function we've just created. In the template, add a click handler to the md-button to call the function `markImportant()` by adding ` @click="markImportant()"` to the `<md-button> tag 
-
 ```html
     <!-- TODO - SVG for use in Exercise3 -->
     <md-button class="important-flag" @click="markImportant()">
@@ -508,9 +536,13 @@
 
 3. The previously failing tests should have started to pass now. With this work done, let's commit our code. On the terminal, run 
 ```bash
-$ git add .
-$ git commit -m "Implementing the todoitem flag"
-$ git push
+git add .
+```
+```bash
+git commit -m "Implementing the todoitem flag"
+```
+```bash
+git push
 ```
 
 3. Open our local todolist app (http://localhost:8080/#/todo). If we try to use our important flag, we should see it's still not behaving as expected; this is because we're not updating the state of the app in response to the click event.
@@ -571,9 +603,13 @@
 
 3. With all our tests now passing, let's commit our code. On the terminal, run
 ```bash
-$ git add .
-$ git commit -m "Implementing the store and actions"
-$ git push
+git add .
+```
+```bash
+git commit -m "Implementing the store and actions"
+```
+```bash
+git push
 ```
 
 3. Before running a build in Jenkins, let's add our tests and code to the develop branch. Ask your neighbour to review your code changes and if they approve; merge them to Develop! (If you're feeling adventurous - raise a PR through GitLab and have someone on your desk peer review it!)
@@ -581,9 +617,13 @@
 NOTE - At this point in a residency we would peer review the code before pushing it to develop or master branch!
 </p>
 ```bash
-$ git checkout develop
-$ git merge feature/important-flag
-$ git push --all
+git checkout develop
+```
+```bash
+git merge feature/important-flag
+```
+```bash
+git push --all
 ```
 
 3. Run a build in Jenkins. If all things were successful; our application should be deployed as expected! Validate the flag is working as expected.
diff --git a/exercises/4-an-enslaved-hope/README.md b/exercises/4-an-enslaved-hope/README.md
index db79e91..2d69618 100644
--- a/exercises/4-an-enslaved-hope/README.md
+++ b/exercises/4-an-enslaved-hope/README.md
@@ -46,7 +46,7 @@
 
 2. On your terminal navigate to your `todolist-api` project and checkout the pipeline feature branch that's been already created for you.
 ```bash
-$ git checkout feature/jenkinsfile
+git checkout feature/jenkinsfile
 ```
 
 2. Open up your `todolist-api` application in your favourite editor and move to the `Jenkinsfile` in the root of the project. The highlevel structure of the file is shown collapsed below. 
@@ -80,9 +80,13 @@
 
 2. With these changes in place, push your changes to the `feature/jenkinsfile` branch.
 ```bash
-$ git add Jenkinsfile
-$ git commit -m "ADD - namespace and git repo to pipeline"
-$ git push
+git add Jenkinsfile
+```
+```bash
+git commit -m "ADD - namespace and git repo to pipeline"
+```
+```bash
+git push
 ```
 
 2. When the changes have been successfully pushed; Open Jenkins.
@@ -104,16 +108,30 @@
 
 2. The pipeline file is setup to only run `bake` & `deploy` stages when on `master` or `develop` branch. This is to provide us with very fast feedback for team members working on feature or bug fix branches. Each time someone commits or creates a new branch a basic build with testing occurs to give very rapid feedback to the team. Let's now update our  `master` and `develop` branches to include the Jenkinsfile and delete the feature branch.
 ```bash
-$ git checkout develop
-$ git merge feature/jenkinsfile
+git checkout develop
+```
+```bash
+git merge feature/jenkinsfile
 # you may get merge conflicts at this point
-$ git add .
-$ git commit -m "Jenkinsfile updates"
-$ git checkout master
-$ git merge develop
-$ git push -u origin --all
+```
+```bash
+git add .
+```
+```bash
+git commit -m "Jenkinsfile updates"
+```
+```bash
+git checkout master
+```
+```bash
+git merge develop
+```
+```bash
+git push -u origin --all
+```
+```bash
 # this is to delete the branch from the remote
-$ git push origin :feature/jenkinsfile
+git push origin :feature/jenkinsfile
 ```
 
 2. Back on Jenkins we should see our `todolist-api` pipelines have changed with the `develop` and `master` now appearing. The feature was deleted so this job should have gone away.
@@ -125,8 +143,10 @@
 
 2.  We can move on to the `todolist-fe` job. The process is the same as before, checkout the feature branch
 ```bash
-$ cd todolist-fe
-$ git checkout feature/jenkinsfile
+cd todolist-fe
+```
+```bash
+git checkout feature/jenkinsfile
 ```
 
 2. Open up your `todolist-fe` application in your favourite editor and move to the `Jenkinsfile` in the root of the project. Update all `<YOUR_NAME>` and `<GIT_USERNAME>` as you did before, including in the prepare environment steps. Check the  `GITLAB_DOMAIN` is set too. 
@@ -134,23 +154,41 @@
 
 2. Commit your changes to your feature branch as you did previously. 
 ```bash
-$ git add Jenkinsfile
-$ git commit -m "ADD - namespace and git repo to pipeline"
-$ git push
+git add Jenkinsfile
+```
+```bash
+git commit -m "ADD - namespace and git repo to pipeline"
+```
+```bash
+git push
 ```
 
 2. This time update your master and develop branches before creating config in Jenkins
 ```
-$ git checkout develop
-$ git merge feature/jenkinsfile
+git checkout develop
+```
+```bash
+git merge feature/jenkinsfile
 # you may get merge conflicts at this point
-$ git add .
-$ git commit -m "Jenkinsfile updates"
-$ git checkout master
-$ git merge develop
+```
+```bash
+git add .
+```
+```bash
+git commit -m "Jenkinsfile updates"
+```
+```bash
+git checkout master
+```
+```bash
+git merge develop
+```
+```bash
 # this is to delete the branch from the remote
-$ git push origin :feature/jenkinsfile
-$ git push -u origin --all
+git push origin :feature/jenkinsfile
+```
+```bash
+git push -u origin --all
 ```
 
 2. On Jenkins; create a new `Multibranch Pipeline` job called `todolist-fe`.
@@ -188,16 +226,22 @@
 
 2. Use the OpenShift Applier to create the cluster content 
 ```bash
-$ cd .openshift-applier
-$ ansible-playbook apply.yml -i inventory/ \
+cd .openshift-applier
+```
+```bash
+ansible-playbook apply.yml -i inventory/ \
      -e "filter_tags=pipeline"
 ```
 
 2. With these changes in place, commit your changes to GitLab
 ```bash
-$ git add .
-$ git commit -m "ADD - ocp pipeline in git repo"
-$ git push
+git add .
+```
+```bash
+git commit -m "ADD - ocp pipeline in git repo"
+```
+```bash
+git push
 ```
 
 2. Login to your OpenShift Cluster and go to the `<YOUR_NAME>-ci-cd` namespace. On the side menu; hit Builds > Pipeline to see your newly created pipeline running in OCP Land.
@@ -225,8 +269,10 @@
 
 2. Use the OpenShift Applier to create the cluster content 
 ```bash
-$ cd todolist-api/.openshift-applier
-$ ansible-playbook apply.yml -i inventory/ \
+cd todolist-api/.openshift-applier
+```
+```bash
+ansible-playbook apply.yml -i inventory/ \
      -e "filter_tags=pipeline"
 ```
 
@@ -235,9 +281,13 @@
 
 2. Commit your changes to GitLab
 ```bash
-$ git add .
-$ git commit -m "ADD - ocp pipeline in git repo"
-$ git push
+git add .
+```
+```bash
+git commit -m "ADD - ocp pipeline in git repo"
+```
+```bash
+git push
 ```
 
 ### Part 3 - Security Scanning Slaves
@@ -248,7 +298,7 @@
 
 3. On your  terminal; move to the `enablement-ci-cd` repo. We already have the `templates/jenkins-slave-generic-template.yml` template we're going to re-use from the previous lab so all we need is to check out the params file
 ```bash
-$ git checkout exercise4/zap-and-arachni params/jenkins-slave-zap
+git checkout exercise4/zap-and-arachni params/jenkins-slave-zap
 ```
 
 3. This should have created the following files which we will fill out. We will use a `ZAP` image hosted on the `rht-labs/ci-cd` repo so there will be no `Dockerfile` needed as we did with the `jenkins-slave-npm` in exercise 2:
@@ -267,7 +317,7 @@
 
 3. Run the ansible playbook filtering with tag `zap` so only the zap build pods are run.
 ```bash
-$ ansible-playbook apply.yml -e target=tools \
+ansible-playbook apply.yml -e target=tools \
      -i inventory/ \
      -e "filter_tags=zap"
 ```
@@ -280,7 +330,7 @@
 
 3. On your terminal; checkout the params and Docker file. The Dockerfile for the `Arachni` scanner is included here and we will point the build to it. 
 ```bash
-$ git checkout exercise4/zap-and-arachni params/jenkins-slave-arachni docker/jenkins-slave-arachni 
+git checkout exercise4/zap-and-arachni params/jenkins-slave-arachni docker/jenkins-slave-arachni 
 ```
 
 3. Create an object in `inventory/host_vars/ci-cd-tooling.yml` called `jenkins-slave-arachni` with the following content:
@@ -304,14 +354,18 @@
 
 3. With these changes in place, push your changes to the `master` branch.
 ```bash
-$ git add .
-$ git commit -m "ADD - Arachni scanning image"
-$ git push
+git add .
+```
+```bash
+git commit -m "ADD - Arachni scanning image"
+```
+```bash
+git push
 ```
 
 3. Run the ansible playbook filtering with tag `arachni` so only the arachni build pods are run.
 ```bash
-$ ansible-playbook apply.yml -e target=tools \
+ansible-playbook apply.yml -e target=tools \
      -i inventory/ \
      -e "filter_tags=arachni"
 ```
diff --git a/exercises/5-non-functionals-strike-back/README.md b/exercises/5-non-functionals-strike-back/README.md
index 5ee32e8..f1befde 100644
--- a/exercises/5-non-functionals-strike-back/README.md
+++ b/exercises/5-non-functionals-strike-back/README.md
@@ -191,9 +191,13 @@
 
 2. With this config in place run a build on Jenkins. To do this; commit your code (from your terminal):
 ```bash
-$ git add .
-$ git commit -m "ADD - security scanning tools to pipeline"
-$ git push
+git add .
+```
+```bash
+git commit -m "ADD - security scanning tools to pipeline"
+```
+```bash
+git push
 ```
 
 2. Check out the Blue Ocean Jenkins view for how the parallel stage is viewed!
@@ -243,9 +247,13 @@
 
 3. Save the `Jenkinsfile` and commit it to trigger a build with some more enhancements.
 ```bash
-$ git add .
-$ git commit -m "ADD - linting and coverage to the pipeline"
-$ git push
+git add .
+```
+```bash
+git commit -m "ADD - linting and coverage to the pipeline"
+```
+```bash
+git push
 ```
 
 3. When the build has completed; fix the linting errors if there are any and commit your changes. Look in Jenkins log for what the issue might be....
diff --git a/exercises/6-return-of-the-app-monitoring/README.md b/exercises/6-return-of-the-app-monitoring/README.md
index eca0b9a..d40a5f6 100644
--- a/exercises/6-return-of-the-app-monitoring/README.md
+++ b/exercises/6-return-of-the-app-monitoring/README.md
@@ -111,9 +111,13 @@
 
 2. Our dashboards are set to show the `Description` field from the `Build Fail Analyser`. Run a build by checking in our failed tests and check the result on the Build Monitor created in the previous step
 ```bash
-$ git add .
-$ git commit -m "TEST - failing build"
-$ git push
+git add .
+```
+```bash
+git commit -m "TEST - failing build"
+```
+```bash
+git push
 ```
 ![fail-dashboard](../images/exercise6/fail-dashboard.png)
 

--
Gitblit v1.9.3