| exercises/2-attack-of-the-pipelines/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/5-non-functionals-strike-back/README.md | ●●●●● patch | view | raw | blame | history | |
| exercises/images/exercise4/jenkins-parallel.png | patch | view | raw | blame | history | |
| exercises/images/exercise4/linting-issue.png | patch | view | raw | blame | history | |
| exercises/images/exercise5/report-location.png | patch | view | raw | blame | history |
exercises/2-attack-of-the-pipelines/README.md
@@ -359,7 +359,7 @@ ### Part 3 - Add configs to cluster > _In this exercise; we will use the OpenShift Applier to drive the creation of cluster content required by the app such as MongoDB and the Apps Build / Deploy Config_ 4. On your terminal navigate to the root of the `todolist-fe` application. The app contains a hidden folder called `.openshift-applier`. Move `cd .openshift-applier` into this directory and you should see a familiar looking directory structure for an ansible playbook. 4. On your terminal navigate to the root of the `todolist-fe` application. The app contains a hidden folder called `.openshift-applier`. Move into this `.openshift-applier` directory and you should see a familiar looking directory structure for an ansible playbook. ``` .openshift-applier ├── README.md @@ -567,7 +567,7 @@ 5. Finally; add the trigger for the next job in the pipeline. Add a post-build action from the dropdown called `Trigger parameterized build on other projects`. * Set the project to build to be `dev-todolist-fe-deploy` * Set the condition to be `Stable`. * Click Add Parameters dropdown and select Current build parameters. This will pass the ${BUILD_TAG} to the downstream job which we will create next. * Click Add Parameters dropdown and select `Current build parameters`. This will pass the `${BUILD_TAG}` to the downstream job which we will create next.  5. Hit save! That's our *bake* phase done! Finally; on to our *deploy* @@ -593,7 +593,7 @@ ```  5. When a deployment has completed; OpenShift can verify it's success. Add another step called by clicking the `Add build Step` on the Build tab then `Verify OpenShift Deployment` including the following: 5. When a deployment has completed; OpenShift can verify it's success. Add another step by clicking the `Add build Step` on the Build tab then `Verify OpenShift Deployment` including the following: * Set the Project to your `<YOUR_NAME>-dev` * Set the DeploymentConfig to your app's name `todolist-fe` * Set the replica count to `1` @@ -603,10 +603,12 @@ #### 4d - Pipeline 5. With our Jenkins setup in place; now move to our `todolist-fe` app's source code. We have to add our configuration to the frontend to tell it where the API layer will be hosted. Open the source in your favourite editor and navigate to `src/config/dev.js`. Update `<YOUR_NAME>` accordingly with the route where the Todo List API will live when it is deployed, update the `somedomain` to the clusters domain. For example: 5. With our Jenkins setup in place; now move to our `todolist-fe` app's source code. We have to add our configuration to the frontend to tell it where the API layer will be hosted. Open the source in your favourite editor and navigate to `src/config/dev.js`. 5. Update `<YOUR_NAME>` accordingly with the route where the Todo List API will live when it is deployed, update the `somedomain` to the clusters domain. The correct full URL can also be found on the OpenShift Console; if you copy it from there remember to append `/api/todos` to the URL. For example:  5. Repeat this for `src/config/test.js` file. Once done; commit your chanages and push them to GitLab 5. Repeat this for `src/config/test.js` file. If you copy the URL from the previous step; change `dev` to `test`. Once done; commit your chanages and push them to GitLab ```bash $ git add . $ git commit -m "ADD config for api" @@ -664,7 +666,7 @@ 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 OpenShifty; 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 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. exercises/5-non-functionals-strike-back/README.md
@@ -73,22 +73,23 @@ } ``` 2. A command to run the tool by passing in the URL of the app we're going to test. 2. Add a `step` with a `sh` command to run the tool by passing in the URL of the app we're going to test. ```groovy stage('OWASP Scan') { agent { node { label "jenkins-slave-zap" agent { node { label "jenkins-slave-zap" } } } when { expression { GIT_BRANCH ==~ /(.*master|.*develop)/ } } steps { sh ''' /zap/zap-baseline.py -r index.html -t ${E2E_TEST_ROUTE} ''' } when { expression { GIT_BRANCH ==~ /(.*master|.*develop)/ } } steps { sh ''' /zap/zap-baseline.py -r index.html -t ${E2E_TEST_ROUTE} || return_code=$? echo "exit value was - " $return_code ''' } } ``` @@ -105,8 +106,8 @@ } steps { sh ''' /zap/zap-baseline.py -r index.html -t http://${E2E_TEST_ROUTE} exit $? /zap/zap-baseline.py -r index.html -t http://${E2E_TEST_ROUTE} || return_code=$? echo "exit value was - " $return_code ''' } post { @@ -166,12 +167,15 @@ $ git push ``` 2. Check out the Blue Ocean Jenkins view for how the parallel stage is viewed!  2. Once the Jobs have completed; navigate to the Jobs status and see the scores. You can find the graphs and test reports on overview of the Job. Explore the results!   <p class="tip"> NOTE - your build may have failed but the reports should still be generated! NOTE - your build may have failed because of the a security failure but the reports should still be generated, it is OK to proceed with the next exercise! </p> ### Part 2 - Add Code Coverage & Linting to the pipeline @@ -179,7 +183,7 @@ 3. Coverage reports are already being generated as part of the tests. We can have Jenkins produce a HTML report showing in detail where our testing is lacking. Open the `todolist-fe` in your favourite editor. 3. Open the `Jenkinsfile` in the root of the project; move to the `stage("node-build"){ ... }` section. In the post section add a block for producing a `HTML` report as part of our builds. 3. Open the `Jenkinsfile` in the root of the project; move to the `stage("node-build"){ ... }` section. In the `post` section add a block for producing a `HTML` report as part of our builds. This is all that is needed for Jenkins to repor the coverage stats. ```groovy // Post can be used both on individual stages and for the entire build. post { @@ -198,12 +202,12 @@ } ``` 3. We will add a new step to our `stage("node-build"){ }` section to lint the Javascript code. After the `npm install`; add a command to run the linting. 3. To get the linting working; we will add a new step to our `stage("node-build"){ }` section to lint the Javascript code. After the `npm install`; add a command to run the linting. ```groovy echo '### Install deps ###' sh 'npm install' echo '### Running linting ###' sh 'npm run lint:ci' sh 'npm run lint' ``` 3. Save the `Jenkinsfile` and commit it to trigger a build with some more enhancements. @@ -213,7 +217,13 @@ $ git push ``` 3. To view the resulting graph; go to the job's build page and open the `Code Coverage` report from the nav bar on the side. Open the report to drill down into detail of where testing coverage could be improved! 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....  3. To view the coverage graph; go to the job's build page and open the `Code Coverage` report from the nav bar on the side.  3. Open the report to drill down into detail of where testing coverage could be improved!  <p class="tip"> NOTE - a good practice for teams is to try and increase the code coverage metrics over the life of a project. Teams will often start low and use practices such as retrospective to increase the quality at specific times. exercises/images/exercise4/jenkins-parallel.png
