| exercises/1-the-manual-menace/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/2-attack-of-the-pipelines/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/3-revenge-of-the-automated-testing/README.md | ●●●●● patch | view | raw | blame | history |
exercises/1-the-manual-menace/README.md
@@ -163,16 +163,16 @@ ansible-galaxy install -r requirements.yml --roles-path=roles ``` 3. Apply the inventory by logging into OpenShift on the terminal and running the playbook as follows (<CLUSTER_URL> should be replaced with the one you've been sent): 3. Apply the inventory by logging into OpenShift on the terminal and running the playbook as follows (<CLUSTER_URL> should be replaced with the one you've been sent as shown below). Accept any insecure connection warning 👍: ```bash oc login <CLUSTER_URL> oc login https://console.lader.rht-labs.com ``` ```bash ansible-playbook apply.yml -i inventory/ -e target=bootstrap ``` where the `-e target=bootstrap` is passing an additional variable specifying that we run the `bootstrap` inventory 3. Once successful you should see an output similar to this:  3. Once successful you should see an output similar to this (Cow's not included):  3. You can check to see the projects have been created successfully by running ```bash @@ -320,9 +320,47 @@ git push -u origin --all ``` #### 5 MongoDB for CI tests > In order to run our API tests in CI in later labs; we need there to be a MongoDB available for executing our tests. As this is part of our CI/CD Lifecycle; we will add it now. 4. In our `enablement-ci-cd` repo; checkout the mongo templates 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 ``` 4. 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. ```yaml - name: "jenkins-mongodb" namespace: "{{ ci_cd_namespace }}" template: "{{ playbook_dir }}/templates/mongodb.yml" params: "{{ playbook_dir }}/params/mongodb" tags: - mongodb ```  4. Git commit your updates to the inventory to git for traceability. ```bash git add . ``` ```bash git commit -m "ADD - mongodb for use in the pipeline" ``` ```bash git push ``` 4. Apply this change as done previously using ansible. The deployment can be validated by going to your `<YOUR_NAME>-ci-cd` namespace and checking if it is there! ```bash ansible-playbook apply.yml -e target=tools \ -i inventory/ \ -e "filter_tags=mongodb" ```  **Note - When making changes to enablement-ci-cd you should frequently commit the changes to git.** ### Part 4 - Jenkins & s2i ### Part 6 - Jenkins & s2i > _Create a build and deployment config for Jenkins. Add new configuration and plugins to the OCP Stock Jenkins using s2i_ 5. Add the Jenkins Build & Deployment configs to the `enablement-ci-cd` repo by merging the contents `exercise1/jenkins` in @@ -451,7 +489,7 @@ 5. When the Jenkins deployment has completed; login (using your openshift credentials) and accept the role permissions. You should now see a fairly empty Jenkins with just the seed job ### Part 5 - Jenkins Hello World ### Part 7 - Jenkins Hello World > _To test things are working end-to-end; create a hello world job that doesn't do much but proves we can pull code from git and that our balls are green._ 6. Log in to Jenkins and hit `New Item` . @@ -464,7 +502,7 @@ 6. Run the build and we should see if pass succesfully and with Green Balls!  ### Part 6 - Live, Die, Repeat ### Part 8 - Live, Die, Repeat > _In this section you will proove the infra as code is working by deleting your Cluster Content and recreating it all_ 7. Commit your code to the new repo in GitLab @@ -496,7 +534,7 @@ 7. Re-apply the inventory to re-create it all! ```bash oc login -p <password> -u <user> <cluster_url> oc login https://console.lader.rht-labs.com ``` ```bash ansible-playbook apply.yml -i inventory/ -e target=bootstrap @@ -510,6 +548,7 @@ ## Extension Tasks > _Ideas for go-getters. Advanced topic for doers to get on with if they finish early. These will usually not have a solution and are provided for additional scope._ - Install Cowsay for 100% more Ansible Fun! - Add more secure access for Nexus (ie not admin / admin123) using the automation to drive secret creation - Add a SonarQube persistent deployment to the `ci-cd-deployments` section. - Add `jenkins.plugins.slack.SlackNotifier.xml` to `jenkins-s2i/configuration` to include URL of Slack for team build notifications and rebuild Jenkins S2I exercises/2-attack-of-the-pipelines/README.md
@@ -677,7 +677,7 @@ 6. If it has been a success we should see our dummyData. This is because there is no backend deployed, in later labs we will deploy the backend and the mongodb for persistence but to do this we will use Jenkins Pipeline as code.  ### Part 6 - (Optional) GitLab Webhooks ### Part 5 - (Optional) GitLab Webhooks > _In this exercise we will link GitLab to Jenkins so that new build jobs are triggered on each push to the `develop` branch._ <p class="tip" > exercises/3-revenge-of-the-automated-testing/README.md
@@ -134,6 +134,9 @@ 2. Click `save` or `apply` at the bottom to save the changes. Run the `dev-todolist-fe-build` job and verify that this passes and the `build` and `bake` jobs are both triggered. #### (Optional) Failing the tests > If you're not very confident in your technical ability and want don't want to do the TDD lab; feel free to just do this next section. If you are confident jump on to the e2e testing section below 2. We're now going to deliberately fail a test to ensure that `bake` and `deploy` jobs aren't triggered if any tests fail. Open the `todolist-fe` source code in your favourite editor. Open `ListOfTodos.spec.js` in `/tests/unit/vue-components` and head to `line 39`. Add `not.` before `toHaveBeenCalled()` to fail the test.  @@ -156,75 +159,7 @@ 2. Undo the changes you made to the `ListOfTodos.spec.js` file, commit your code and rerun the build. This should trigger a full `build --> bake --> deploy` of `todolist-fe`. #### 1b - BE Unit tests > In this exercise we will execute our test for the backend locally. Once verified we will add them to Jenkins and add a mongodb to Jenkins for running tests there. 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 ``` 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. ```yaml - name: "jenkins-mongodb" namespace: "{{ ci_cd_namespace }}" template: "{{ playbook_dir }}/templates/mongodb.yml" params: "{{ playbook_dir }}/params/mongodb" tags: - mongodb ```  2. Git commit your updates to the inventory to git for traceability. ```bash 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 \ -i inventory/ \ -e "filter_tags=mongodb" ```  2. With the mongodb in place Open up Jenkins and head to the `configure` panel of the `dev-todolist-api-build` job. 2. Add `npm run test:ci` above `npm run build:ci`.  2. Scroll to the `Post-build Actions` section and click `Add post-build action`. Select `Publish xUnit test result report`. 2. Click the `Add` button under `Publish xUnit test result report` and select `JUnit`. In the pattern field enter `reports/server/mocha/test-results.xml`. In the `Failed Tests Thresholds` input box enter 0 under `Red Ball Total`. It should look a little something like this. Save your changes:  2. We're now going to deliberately fail a test again to ensure that `bake` and `deploy` jobs aren't triggered if any tests fail. Go to `todo.spec.js` in `/server/api/todo` and head to `line 35`. Replace `false` with `true`.  2. Push this to Gitlab and run the build job. ```bash 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. <p class="tip"> NOTE - Don't forget to undo the changes that you made to your tests! </p> #### 1c - End to End tests (e2e) #### 1b - End to End tests (e2e) > _Unit tests are a great way to get immediate feedback as part of testing an application. End to end tests that drive user behaviour are another amazing way to ensure an application is behaving as expected._ In this exercise we will add a new stage to our pipeline called `dev-todolist-fe-e2e` that will run after the deploy has been completed. End to end tests will use Nightwatchjs to orchestrate a selenium webdriver instance that controls the web browser; in this case Chrome!
