| 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/4-an-enslaved-hope/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/images/exercise1/jenkins-mongo.png | patch | view | raw | blame | history | |
| exercises/images/exercise4/zap-object.png | 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 @@ -197,7 +197,7 @@ 4. The essential params to include in this file are: ```bash VOLUME_CAPACITY=5Gi MEMORY_LIMIT=2Gi MEMORY_LIMIT=1Gi ``` 4. Create a new object in the inventory variables `inventory/host_vars/ci-cd-tooling.yml` called `ci-cd-tooling` and populate it's `content` is as follows @@ -320,9 +320,47 @@ git push -u origin --all ``` ### Part 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 exercise1/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-tooling` 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 @@ -333,14 +371,14 @@ 5. As before; create a new set of params by creating a `params/jenkins` file and adding some overrides to the template and updating the `<YOUR_NAME>` value accordingly. ``` MEMORY_LIMIT=8Gi MEMORY_LIMIT=3Gi VOLUME_CAPACITY=10Gi JVM_ARCH=x86_64 NAMESPACE=<YOUR_NAME>-ci-cd JENKINS_OPTS=--sessionTimeout=720 ``` 5. Add a `jenkins` variable to the ansible inventory underneath the nexus (and git if you have it) in `inventory/host_vars/ci-cd-tooling.yml`. 5. Add a `jenkins` variable to the ansible inventory underneath the jenkins-mongo (and git if you have it) in `inventory/host_vars/ci-cd-tooling.yml`. ```yaml - name: "jenkins" namespace: "{{ ci_cd_namespace }}" @@ -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
@@ -589,7 +589,9 @@ Remember to replace `<YOUR_NAME>` accordingly. ```bash #!/bin/bash curl -v -f http://admin:admin123@${NEXUS_SERVICE_HOST}:${NEXUS_SERVICE_PORT}/repository/zip/com/redhat/todolist/${BUILD_TAG}/package-contents.zip -o package-contents.zip curl -v -f \ http://admin:admin123@${NEXUS_SERVICE_HOST}:${NEXUS_SERVICE_PORT}/repository/zip/com/redhat/todolist/${BUILD_TAG}/package-contents.zip \ -o package-contents.zip unzip package-contents.zip oc project <YOUR_NAME>-ci-cd NAME=todolist-fe @@ -669,55 +671,13 @@ 5. You should now see the pipeline view. Run the pipeline by hitting run (you can move onto the next part while it is running as it may take some time).  ### Part 5 - (Optional) Backend Pipeline > In this exercise we will use the Jobs created for the `todolist-fe` as a template to create a pipeline for the `todolist-api` app by copying the config. The backend pipeline as code will be explored in the next lab 6. On Jenkins home; create a new job for our backend build called `dev-todolist-api-build`. Use the `Copy from` section to copy all the configuration from the `dev-todolist-fe-build`.  6. When this has loaded; find and replace both occurrences `-fe` with `-api` within the Job's configuration. Places to make sure you check are: * The GitLab project URL * Projects to build on the Post Build Action 6. On the Build tab; remove the `:dev` from the `npm run build:ci:dev` so the line reads. The rest of the instructions can be left as they are. ```bash npm run build:ci ```  6. Save the configuration for `dev-todolist-api-build` 6. On Jenkins home; create a new job for our backend bake called `dev-todolist-api-bake`. Use the Copy from section to copy all the configuration from the `dev-todolist-fe-bake` as you've just done. 6. When this has loaded; find and replace the occurrences `-fe` with `-api` within the Job's configuration. Places to make sure you check are: * The BUILD_TAG default value and description * NAME in the execute shell step * Projects to build on the Post Build Action 6. Save the configuration for `dev-todolist-api-build` 6. On Jenkins home; create a new job for our backend build called `dev-todolist-api-deploy`. Use the Copy from section to copy all the configuration from the `dev-todolist-fe-deploy` as you've just done. 6. When this has loaded; find and replace the occurrences `-fe` with `-api` within the Job's configuration. Places to make sure you check are: * The BUILD_TAG default value and description * NAME in the execute shell step * The name of the DeploymentConfig to validate in the Verify OpenShift Deployment 6. Save the configuration for `dev-todolist-api-deploy` and that's it for wiring together our `todolist-api` pipeline. 6. Run the `dev-todolist-api-build` to trigger the backend pipeline. While this is building, check our front end app and see if it has deployed successfully. 6. To check the deployment in OpenShift; open the console and go to your `dev` namespace. You should see the deployment was successful; hit the URL to open the app (the screenshot below has both apps deployed). 6. To check the deployment in OpenShift; open the web console and go to your `dev` namespace. You should see the deployment was successful; hit the URL to open the app (the screenshot below has both apps deployed).  6. If it has been a success we should see our dummyData. This is because there is no backend deployed. 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.  6. When `dev-todolist-api-build` has completed we should see the sample data has changed on refresh.  ### 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" > @@ -743,14 +703,6 @@  7. We can now test this properly by heading into the `todolist-fe` repository through <YOUR_FAVOURITE_EDITOR>. Make a small change to your code, then commit and push it, ensuring you're on the develop branch. Then head over to Jenkins and wait until the `dev-todolist-fe-build` job has been triggered. 7. All that's left to do is to repeat the same steps for `todolist-api` (Starting from step 3): Create Build Trigger: `https://jenkins-<YOUR_NAME>-ci-cd.apps.some.domain.com/job/dev-todolist-api-build/configure` Create GitLab Integration: `https://gitlab-<YOUR_NAME>-ci-cd.apps.some.domain.com/donal/todolist-api/settings/integrations` Check your build status and you should see something like this. With `Started by Gitlab push by <YOUR_NAME>`:  7. We now have a working GitLab webhook so any time we push code it will automatically build! Next up we'll show you how to add tests to your pipeline.
@@ -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! exercises/4-an-enslaved-hope/README.md
@@ -345,7 +345,7 @@ 3. Update the `jenkins-slave-arachni` files `SOURCE_REPOSITORY_URL` to point to your gitlab's hosted version of the `enablement-ci-cd` repo. ``` SOURCE_REPOSITORY_URL=https://gitlab.apps.<SOME_DOMAIN>.com/<GIT_USERNAME>/enablement-ci-cd.git SOURCE_REPOSITORY_URL=https://gitlab.apps.lader.rht-labs.com/<GIT_USERNAME>/enablement-ci-cd.git SOURCE_CONTEXT_DIR=docker/jenkins-slave-arachni BUILDER_IMAGE_NAME=registry.access.redhat.com/openshift3/jenkins-slave-base-rhel7:latest NAME=jenkins-slave-arachni exercises/images/exercise1/jenkins-mongo.png
