Introduce test of html and epub

This is an indirect way of checking the structure of the book, the
asciidoc syntax and the external links.

Author: jnavila

Gemfile

@@ -12,4 +12,5 @@ gem 'asciidoctor-pdf', '1.5.3'
 gem 'coderay', '1.1.3'
 gem 'pygments.rb', '1.2.1'
 gem 'thread_safe', '0.3.6'
-gem 'epubcheck', '3.0.1'
+gem 'epubcheck-ruby'
+gem 'html-proofer'

Rakefile

@@ -1,4 +1,11 @@
 namespace :book do
+  def exec_or_raise(command)
+    puts `#{command}`
+    if (! $?.success?)
+      raise "'#{command}' failed"
+    end
+  end
+
   desc 'build basic book formats'
   task :build do
 
@@ -16,10 +23,14 @@ namespace :book do
       `bundle exec asciidoctor #{params} -a data-uri progit.asc`
       puts " -- HTML output at progit.html"
 
+      exec_or_raise('htmlproofer --check-html progit.html')
+
       puts "Converting to EPub..."
       `bundle exec asciidoctor-epub3 #{params} progit.asc`
       puts " -- Epub output at progit.epub"
 
+      exec_or_raise('epubcheck progit.epub')
+
       # Commented out the .mobi file creation because the kindlegen dependency is not available.
       # For more information on this see: #1496.
       # This is a (hopefully) temporary fix until upstream asciidoctor-epub3 is fixed and we can offer .mobi files again.

book/03-git-branching/sections/workflows.asc

@@ -23,7 +23,7 @@ It's generally easier to think about them as work silos, where sets of commits g
 
 [[lrbranch_b]]
 .A "`silo`" view of progressive-stability branching
-image::images/lr-branches-2.png[A "`silo`" view of progressive-stability branching]
+image::images/lr-branches-2.png[A “silo” view of progressive-stability branching']
 
 You can keep doing this for several levels of stability.
 Some larger projects also have a `proposed` or `pu` (proposed updates) branch that has integrated branches that may not be ready to go into the `next` or `master` branch.

book/04-git-server/sections/gitlab.asc

@@ -30,7 +30,7 @@ After you've logged in, click the "`Admin area`" icon in the menu at the top rig
 
 [[gitlab_menu]]
 .The "`Admin area`" item in the GitLab menu
-image::images/gitlab-menu.png[The `"Admin area`" item in the GitLab menu]
+image::images/gitlab-menu.png[The “Admin area” item in the GitLab menu]
 
 ===== Users
 

book/06-github/sections/1-setting-up-account.asc

@@ -33,12 +33,12 @@ If you don't already have one, see <<ch04-git-on-the-server#_generate_ssh_key>>.
 Open up your account settings using the link at the top-right of the window:
 
 .The "`Account settings`" link
-image::images/account-settings.png[The "`Account settings`" link]
+image::images/account-settings.png[The “Account settings” link]
 
 Then select the "`SSH keys`" section along the left-hand side.
 
 .The "`SSH keys`" link.
-image::images/ssh-keys.png[The "`SSH keys`" link]
+image::images/ssh-keys.png[The “SSH keys” link]
 
 From there, click the "`Add an SSH key`" button, give your key a name, paste the contents of your `~/.ssh/id_rsa.pub` (or whatever you named it) public-key file into the text area, and click "`Add key`".
 
@@ -55,7 +55,7 @@ Next, if you wish, you can replace the avatar that is generated for you with an
 First go to the "`Profile`" tab (above the SSH Keys tab) and click "`Upload new picture`".
 
 .The "`Profile`" link
-image::images/your-profile.png[The "`Profile`" link]
+image::images/your-profile.png[The “Profile” link]
 
 We'll choose a copy of the Git logo that is on our hard drive and then we get a chance to crop it.
 

book/06-github/sections/2-contributing.asc

@@ -21,7 +21,7 @@ This opens up a discussion thread with code review, and the owner and the contri
 To fork a project, visit the project page and click the "`Fork`" button at the top-right of the page.
 
 .The "`Fork`" button
-image::images/forkbutton.png[The "`Fork`" button]
+image::images/forkbutton.png[The “Fork” button]
 
 After a few seconds, you'll be taken to your new project page, with your own writeable copy of the code.
 
@@ -123,7 +123,7 @@ To https://github.com/tonychacon/blink
 
 Now if we go back to our fork on GitHub, we can see that GitHub noticed that we pushed a new topic branch up and presents us with a big green button to check out our changes and open a Pull Request to the original project.
 
-You can alternatively go to the "`Branches`" page at `https://github.com/<user>/<project>/branches` to locate your branch and open a new Pull Request from there.
+You can alternatively go to the "`Branches`" page at `\https://github.com/<user>/<project>/branches` to locate your branch and open a new Pull Request from there.
 
 .Pull Request button
 image::images/blink-02-pr.png[Pull Request button]

book/06-github/sections/3-maintaining.asc

@@ -9,16 +9,16 @@ Let's create a new repository to share our project code with.
 Start by clicking the "`New repository`" button on the right-hand side of the dashboard, or from the `+` button in the top toolbar next to your username as seen in <<_new_repo_dropdown>>.
 
 .The "`Your repositories`" area
-image::images/newrepo.png[The "`Your repositories`" area]
+image::images/newrepo.png[The “Your repositories” area]
 
 [[_new_repo_dropdown]]
 .The "`New repository`" dropdown
-image::images/new-repo.png[The "`new repository`" dropdown]
+image::images/new-repo.png[The “new repository” dropdown]
 
 This takes you to the "`new repository`" form:
 
 .The "`new repository`" form
-image::images/newrepoform.png[The "`new repository`" form]
+image::images/newrepoform.png[The “new repository” form]
 
 All you really have to do here is provide a project name; the rest of the fields are completely optional.
 For now, just click the "`Create Repository`" button, and boom – you have a new repository on GitHub, named `<user>/<project_name>`.
@@ -27,7 +27,7 @@ Since you have no code there yet, GitHub will show you instructions for how to c
 We won't belabor this here; if you need a refresher, check out <<ch02-git-basics-chapter#ch02-git-basics-chapter>>.
 
 Now that your project is hosted on GitHub, you can give the URL to anyone you want to share your project with.
-Every project on GitHub is accessible over HTTPS as `https://github.com/<user>/<project_name>`, and over SSH as `[email protected]:<user>/<project_name>`.
+Every project on GitHub is accessible over HTTPS as `\https://github.com/<user>/<project_name>`, and over SSH as `\[email protected]:<user>/<project_name>`.
 Git can fetch from and push to both of these URLs, but they are access-controlled based on the credentials of the user connecting to them.
 
 [NOTE]

book/08-customizing-git/sections/attributes.asc

@@ -198,14 +198,14 @@ These filters can be set to do all sorts of fun things.
 
 [[filters_a]]
 .The "`smudge`" filter is run on checkout
-image::images/smudge.png[The "`smudge`" filter is run on checkout]
+image::images/smudge.png[The “smudge” filter is run on checkout]
 
 [[filters_b]]
 .The "`clean`" filter is run when files are staged
-image::images/clean.png[The "`clean`" filter is run when files are staged]
+image::images/clean.png[The “clean” filter is run when files are staged]
 
 The original commit message for this feature gives a simple example of running all your C source code through the `indent` program before committing.
-You can set it up by setting the filter attribute in your `.gitattributes` file to filter `*.c` files with the "`indent`" filter:
+You can set it up by setting the filter attribute in your `.gitattributes` file to filter `\*.c` files with the "`indent`" filter:
 
 [source,ini]
 ----

book/10-git-internals/sections/environment.asc

@@ -55,8 +55,8 @@ A "`pathspec`" refers to how you specify paths to things in Git, including the u
 These are used in the `.gitignore` file, but also on the command-line (`git add *.c`).
 
 *`GIT_GLOB_PATHSPECS`* and *`GIT_NOGLOB_PATHSPECS`* control the default behavior of wildcards in pathspecs.
-If `GIT_GLOB_PATHSPECS` is set to 1, wildcard characters act as wildcards (which is the default); if `GIT_NOGLOB_PATHSPECS` is set to 1, wildcard characters only match themselves, meaning something like `*.c` would only match a file _named_ "`*.c`", rather than any file whose name ends with `.c`.
-You can override this in individual cases by starting the pathspec with `:(glob)` or `:(literal)`, as in `:(glob)*.c`.
+If `GIT_GLOB_PATHSPECS` is set to 1, wildcard characters act as wildcards (which is the default); if `GIT_NOGLOB_PATHSPECS` is set to 1, wildcard characters only match themselves, meaning something like `\*.c` would only match a file _named_ "`\*.c`", rather than any file whose name ends with `.c`.
+You can override this in individual cases by starting the pathspec with `:(glob)` or `:(literal)`, as in `:(glob)\*.c`.
 
 *`GIT_LITERAL_PATHSPECS`* disables both of the above behaviors; no wildcard characters will work, and the override prefixes are disabled as well.
 

book/A-git-in-other-environments/sections/visualstudio.asc

@@ -18,7 +18,7 @@ This is a hub for performing Git actions; when you're _writing_ code, you'll pro
 
 [[vs_home]]
 .The "Home" view for a Git repository in Visual Studio
-image::images/vs-2.png[The "`Home`" view for a Git repository in Visual Studio]
+image::images/vs-2.png[The “Home” view for a Git repository in Visual Studio]
 
 Visual Studio now has a powerful task-focused UI for Git.
 It includes a linear history view, a diff viewer, remote commands, and many other capabilities.

book/B-embedding-git/sections/dulwich.asc

@@ -40,5 +40,5 @@ porcelain.log('.', max_entries=1)
 
 ==== Further Reading
 
- * The official API documentation is available at https://www.dulwich.io/apidocs/dulwich.html[].
+ * The official API documentation is available at https://www.dulwich.io/docs/api/
  * Official tutorial at https://www.dulwich.io/docs/tutorial[] has many examples of how to do specific tasks with Dulwich.