ci: Use Travis dpl v2 to deploy on GitHub Pages

[jwflory]

This commit is a follow-up to discussion in #rit-foss-admin about how
the site is deployed from the latest master branch. tl;dr: This
switches us to the beta release of Travis's deployment API:

https://docs.travis-ci.com/user/deployment-v2/providers/pages/

I'm breaking this commit message into two parts: expected outcome and
why I think this works.

Expected outcome

Only applicable to builds on master. Travis builds Jekyll static
content in CI job. If build is successful, clone repo and check out
master branch. Keep dependencies installed in .bundle/ and vendor/
untracked. Push static content to GitHub Pages.

I referenced a dpl v1 job to see how this works before:

https://travis-ci.org/FOSSRIT/fossrit.github.io/builds/659540947

Why I think this works

The git directory is not cleaned up after previous steps, so everything
generated in the jekyll build step should still be present in the
build. This is why cleanup: false was set in the .travis.yml before,
but this is the default behavior in dpl v2:

https://docs.travis-ci.com/user/deployment-v2#cleaning-up-the-git-working-directory

Given that name and email for git commits use the current git commit
author name and email, I am making a bet that the site is deployed
without adding commits to the target branch. I believe jekyll build is
run and no new files are committed to the repo. If this were true, it
would mean .bundle/ and vendor/ would be committed to master, as I
understand it. Which is not the case. _site/ is ignored in the
.gitignore.

Unfortunately there is no way to test this PR until it is merged to
master, since the deployment phase only works on the default branch.
But it will be interesting to see what happens.

cc: @ct-martin

[ct-martin]

@jwflory please use a fork of the repo to test this before it gets merged

[jwflory]

@ct-martin Is there known risk about these changes? Given that this PR is non-breaking and setting up the Travis bits in a fork takes more time, I prefer to go ahead and merge this here.

Also, see the existing example of this Travis deployment workflow that I brought up in #rit-foss-admin:

https://github.com/librecorps/poc_vuepress_docs

https://librecorps.github.io/poc_vuepress_docs/

[ct-martin]

@jwflory if the previous pipeline runs you might overwrite master on this repo. Just be prepared with a local copy you can force-push. Also, see comment in channel about that config

[ct-martin]

So based on Travis logs, the other build scripts doesn't seem to be working right. Still going to maintain my case here though; please test in a fork or be prepared to force-push. I think this is safe, but I'm not sure and don't have time to check right now

[jwflory]

@ct-martin is right. This is more nuanced than I realized. I'm going to close this PR. I'll probably stick with dpl v1, but switch to deploy the site from a gh-pages branch instead that Travis pushes to. I'm going to revisit this sometime next week.