remove shell and confusing npm i

donal

2018-05-09 58480f18403a3e74f9afa99d15c8a89ffaeeec2a

remove shell and confusing npm i

 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
```


 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.

 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"
```

 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....

 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)