Makes everyone fail the pre-commit checks in the morning session (MetOffice#72)

* Makes everyone fail the pre-commit checks in the morning session

* Fix image links and delete JPEGs

---------

Co-authored-by: Ronnie Dutta <[email protected]>

Author: astroDimitrios

episodes/01-issues.md

@@ -32,7 +32,7 @@ Here's some advice for writing good Issues:
 - Break up large Issues into several small ones and or
   use checklists to track tasks in the Issue
 
-Open an Issue on the `git-training-demo` repository 
+Open an Issue on the `git-training-demo` repository
 to add a file stating your favourite cloud type.
 
 Navigate to the **Issues** tab:
@@ -46,7 +46,7 @@ to provide templates for bugs and feature requests.
 Click on the green **Get started** button next to the
 **Feature request** option:
 
-![](fig/github-fork-issue-1.jpeg){alt='A screenshot of the git-training-demo repository showing an Issue being opened. The template has automatically added text to the description and labelled the Issue as an enhancement.'}
+![](fig/github-fork-issue-1.png){alt='A screenshot of the git-training-demo repository showing an Issue being opened. The template has automatically added text to the description and labelled the Issue as an enhancement.'}
 
 You can see the Issue has text in the description already.
 This is from the template which provides a consistent
@@ -93,7 +93,7 @@ On the right hand side of the Issue you can:
 you are working on it.
 2. Add the Issue to a Project by clicking on the cog
 next to the Projects section. (If you don't see a project
-related to the training you might not have been granted permissions, 
+related to the training you might not have been granted permissions,
 ask your instructors for help)
 3. Assign the Issue to a milestone.
 

episodes/03-feature-branch.md

@@ -109,9 +109,18 @@ $ cat cloud-mo-fitzroy.md
 ```output
 # My Favourite Cloud
 
-Light and fluffy cumulus.
+Light and fluffy cumulus.    
 ```
 
+::: caution
+
+## Add in whitespace!
+
+To demonstrate automated testing via GitHub,
+add some spaces to the end of a line in your file.
+
+:::
+
 Add and commit your changes:
 
 ```bash
@@ -139,10 +148,10 @@ Compressing objects: 100% (2/2), done.
 Writing objects: 100% (3/3), 357 bytes | 178.00 KiB/s, done.
 Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
 remote: Resolving deltas: 100% (1/1), completed with 1 local object.
-remote: 
+remote:
 remote: Create a pull request for '1_favourite_cloud' on GitHub by visiting:
 remote:      https://github.com/MetOffice/git-training-demo/pull/new/1_favourite_cloud
-remote: 
+remote:
 To github.com:metoffice/git-training-demo.git
  * [new branch]      1_favourite_cloud -> 1_favourite_cloud
 branch '1_favourite_cloud' set up to track 'origin/1_favourite_cloud'.
@@ -222,7 +231,6 @@ associated with a repository. Here are some of the most useful ones:
 - `git remote rename [oldname] [newname]` changes the local alias by which a remote
   is known - its name. For example, one could use this to change `upstream` to `mo-fitzroy`.
 
-
 ::::::::::::::::::::::::::::::::::::::::::::::::::
 
 ## Open a PR
@@ -277,7 +285,7 @@ In the description scroll down to the checklists
 which look like this:
 
 ```md
-- [ ] I have read `CONTRIBUTING.md` and added my name as a Code Contributor.
+- [ ] I have read `CONTRIBUTING.md`.
 ```
 
 Some open source projects require you to add your name
@@ -287,45 +295,33 @@ Replace the space in the square checkbox brackets with an `x`
 to mark the task as complete:
 
 ```md
-- [x] I have read `CONTRIBUTING.md` and added my name as a Code Contributor.
+- [x] I have read `CONTRIBUTING.md`.
 ```
 
 Now when you open the PR it should look something like this:
 
-![](fig/github-fork-pr-1.jpeg){alt='A screenshot of a users  pull request from their fork back to the upstream git-training-demo repository.'}
+![](fig/github-fork-pr-1.png){alt='A screenshot of a users  pull request from their fork back to the upstream git-training-demo repository.'}
 
-This image shows PR number `#8`.
-This PR will close/fix Issue number `#7` (the top left arrow).
+This image shows PR number `#2`.
+This PR will close/fix Issue number `#1` (the top left arrow).
 You can request a review on the top right.
 Some repositories will be set up to automatically assign
 a reviewer based on how many reviews each team member
 currently has open[^auto-assign-pr-review].
+The middle arrow is where you assign yourself to the PR.
 The bottom arrow shows the checklist items we marked as complete.
 
 At the bottom of your PR you can see that a review is required
-before merging.
-All checks have passed, this repository has automatic checks
+before merging and some checks were not successful.
+This repository has automatic checks
 for trailing whitespace, accidentally adding large files etc.
-More information can be found in the optional episode on
+More information on setting up these checks
+can be found in the optional episode on
 [pre-commit hooks](./09-pre-commit.md).
 
-::: caution
-
-## Help: Some checks have failed
-
-If your now open Pull Request says some checks have failed
-this is because your changes did not pass the automatic
-pre-commit checks.
-
-Click on the **Details** link next to the failed test
-and fix your code on your local repository.
-Commit and then push this fix to GitHub.
-Your PR will automatically update and re-run the tests,
-you may need to refresh the page.
+::: callout
 
-:::
-
-### Automatically closing Issues via PRs
+## Automatically closing Issues via PRs
 
 A PR can automatically close an Issue when it is merged into `main`.
 To use this GitHub functionality
@@ -345,8 +341,61 @@ Make sure you change `1` to your Issue number.
 The [GitHub Documentation](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue) has more information
 on linking PRs to Issues.
 
+:::
+
+## Fixing Failing Checks
+
+Your changes did not pass the automatic pre-commit checks.
+The quickest way to check why a test failed is to click on
+the **Pull request checks / pre-commit** link near the bottom
+of the PR.
+Or you can navigate to the **Checks** tab in the PR,
+then select **Pull request checks** and click on the failing test.
+
+![](fig/pre-commit-check-fail-1.png){alt='A screenshot of a users failing pre-commit check showing the whitespace test has failed.'}
+
+You can see in the test output trailing whitespace has been found.
+This caused the tests to fail.
+Lower down in the output you will see the filename,
+and a diff of the line with the whitespace.
+
+Go back to your local repository and remove the whitespace:
+
+```bash
+$ nano cloud-mo-fitzroy.md
+$ cat cloud-mo-fitzroy.md
+```
+
+```output
+# My Favourite Cloud
+
+Light and fluffy cumulus.
+```
+
+Add and commit your changes:
+
+```bash
+$ git add cloud-mo-fitzroy.md
+$ git commit -m "Removes whitespace"
+```
+
+```output
+[1_favourite_cloud c74c7e1] Removes whitespace
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+```
+
+Push these changes to GitHub:
+
+```bash
+$ git push
+```
+
+Navigate back to your PR.
+You should now see a message saying all checks have passed.
+Merging is still blocked until a colleague reviews our code.
+
 In the next episode we will look at how these changes
-are reviewed and merged back into `main` in more detail.
+are reviewed and merged back into `main`.
 
 :::::::::::::::::::::::::::::::::::::::  challenge
 
@@ -361,7 +410,7 @@ On the right hand side of the PR you can also:
 2. Add labels to the PR.
 3. Add the PR to a Project by clicking on the cog
 next to the Projects section. (If you don't see a project
-related to the training you might not have been granted permissions, 
+related to the training you might not have been granted permissions,
 ask your instructors for help)
 4. Assign the PR to a milestone.
 

episodes/04-review.md

@@ -103,7 +103,8 @@ When you're finished click the green **Submit review** button.
 
 ![](fig/pr-suggestion-2.png){alt='A screenshot of a PR showing the diff in the Files changed tab showing the review popup.'}
 
-The PRs **Conversation** tab now looks like this:
+The PRs **Conversation** tab now looks like this
+towards the bottom of the page:
 
 ![](fig/pr-review-1.png){alt='A screenshot of a PR showing the Conversation tab with a review that has requested changes.'}
 

episodes/05-forks.md

@@ -152,10 +152,10 @@ Compressing objects: 100% (3/3), done.
 Writing objects: 100% (3/3), 369 bytes | 123.00 KiB/s, done.
 Total 3 (delta 1), reused 0 (delta 0), pack-reused 0
 remote: Resolving deltas: 100% (1/1), completed with 1 local object.
-remote: 
+remote:
 remote: Create a pull request for '2_update_favourite_cloud' on GitHub by visiting:
 remote:      https://github.com/mo-fitzroy/git-training-demo/pull/new/2_update_favourite_cloud
-remote: 
+remote:
 To github.com:mo-fitzroy/git-training-demo.git
  * [new branch]      2_update_favourite_cloud -> 2_update_favourite_cloud
 branch '2_update_favourite_cloud' set up to track 'origin/2_update_favourite_cloud'.
@@ -173,7 +173,7 @@ from a Fork[^link-pr-issue].
 [^link-pr-issue]: The [GitHub Documentation](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue) has more information
 on linking PRs to Issues.
 
-![](fig/github-fork-pr-open.jpeg){alt='A screenshot of a user opening a pull request from their fork back to the upstream git-training-demo repository. The description has been autofilled with the pull request template contents.'}
+![](fig/github-fork-pr-open.png){alt='A screenshot of a user opening a pull request from their fork back to the upstream git-training-demo repository. The description has been autofilled with the pull request template contents.'}
 
 The PR will now need to be approved and merged by your instructors.
 
@@ -339,7 +339,7 @@ sequenceDiagram
 - A fork is a server side, in our case GitHub, copy
   of the repository.
 - Forks allow collaborators to contribute to the main
-  repository without being given 
+  repository without being given
   collaborator access or write permissions.
 
 ::::::::::::::::::::::::::::::::::::::::::::::::::