Use Travis CI to test the book build and then deploy it to the site, take 2

[berquist]

Continuation of #284.

Don't merge this yet, because things need to be added.

The last PR failed in three ways:

1. The site went down because the CNAME for custom domain redirection was not present. After checking the log (which I saved), if you're curious, I noticed that there are several other files present in algorithm-archivists.github.io that do not come from either the main repo or building the book. These can persist because update_site.sh only copies files over, rather than wipe and move. This is personal preference, but I think the website repo should be entirely reproducible from the main repo via this script. You can see the difference by comparing your website repo with mine. Let me know which path you'd rather take, and I'll either need to add those files to the main repo and have them copy over during deploy, or have the deploy copy the build rather than wipe the book repo.

2. The guard for when the book should be deployed was wrong. Once the initial PR was merged, every Travis pull_request build (see below) was going to try deploy. This is before the merge actually happens. I don't think Travis would continue to this step if the build failed earlier, but it's still wrong.

3. A bunch of files got deleted. I still don't know how this happened, because I think they should have been present in the book build. I don't think they were extra files left over from before the flattening, either.

---

For reference, and because I didn't understand it for a while, there are two kinds of Travis builds:

1. push:

   • Under the status dialog, this is called Travis CI - Branch and continuous-integration/travis-ci/push.
   • "This is a normal build for the branch. You should be able to reproduce it by checking out the branch locally."
   • What it does is test the branch as-is. By default, this will run for everyone who has a fork of the main repo every time they push to their own fork.

2. pull_request:

   • Under the status dialog, this is called Travis CI - Pull Request and continuous-integration/travis-ci/pr.
   • "This is a pull request build. It is running a build against the merge commit, after merging . Any changes that have been made to the master branch before the build ran are also included."
   • What is does is it simulates merge specified by the PR, then runs the Travis config. This only runs after creating a pull request.

The reason each type of CI run appears twice is that the former leads to the pretty GitHub summary, and the latter leads to the actual Travis log.

The config is now set up so that only push commits to master will deploy to algorithm-archivists.github.io. I checked, and this works in all cases: when there's a merge commit, a rebase and FF merge, a squash and merge, or a regular commit. Any time the history of master is updated, the book will be built and deployed.

---

Note that I changed the names of some environment variables you must set in Travis to be more explicit. Hopefully things are clearer now.

[berquist]

Now that Travis has been activated, you can see that the pr/pull_request build didn't deploy to the book, which would have broken the site...again...

[leios]

Ok. I think we are ready to give this another go, but I would like for @berquist to be available when we merge this PR just in case... So maybe we should set up a time to give this a shot on discord?

[berquist]

Sure. I won't be around Monday EST, but any time from Tuesday EST on is fine.

In the meantime, read the first paragraph again. This PR needs to be updated before merging, otherwise the site will break.

[leios]

Mind if I add a WIP to the title to reflect this?

[berquist]

Go right ahead. Just to be clear, what changes I make next depend on your decision about point 1.

…

On Sun, Aug 5, 2018 at 6:00 PM James Schloss ***@***.***> wrote: Mind if I add a WIP to the title to reflect this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Falgorithm-archivists%2Falgorithm-archive%2Fpull%2F316%23issuecomment-410551241&data=01%7C01%7Cerb74%40pitt.edu%7C1bf6a44a39fb4ff9241a08d5fb1ec997%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=O9%2Fs6l4M3dfoAHqXWuGhce5w1udGE0mwDXS7v%2FJFLn0%3D&reserved=0>, or mute the thread <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAsaEwWpU7RASZP8wluRvqoSjTT08AQ3ks5uN2regaJpZM4VljIQ&data=01%7C01%7Cerb74%40pitt.edu%7C1bf6a44a39fb4ff9241a08d5fb1ec997%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=mvDjO1E2EabpmUy96YZAIS0roUoTgkNQiqE%2F41kumww%3D&reserved=0> .

[leios]

So to be clear: you are arguing there are a lot of extra files because...

update_site.sh only copies files over, rather than wipe and move. This is personal preference, but I think the website repo should be entirely reproducible from the main repo via this script.

I'm up for updating the update_site command. What do we need to do with the CNAME stuff?

[berquist]

Uncommenting this line will take care of CNAME. I still need time to check the rest of the files.

However, there is a new problem: https://travis-ci.org/algorithm-archivists/algorithm-archive/builds/409608474#L427. If you go to https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions:

Travis CI makes encrypted variables and data available only to pull requests coming from the same repository. These are considered trustworthy, as only members with write access to the repository can send them.

Pull requests sent from forked repositories do not have access to encrypted variables or data.

If your build relies on encrypted variables to run, for instance to run Selenium tests with BrowserStack or Sauce Labs, your build needs to take this into account. You won’t be able to run these tests for pull requests from external contributors.

To work around this, restrict these tests only to situations where the environment variables are available, or disable them for pull requests entirely, as shown in the following example:

I need to figure out if the AAA will be affected by this. I think so, because I am on another org's repo, but for some reason this PR ran fine? It will take some investigation. Maybe later this week is best.

[leios]

Oh man, this is getting super messy. Take your time. We really appreciate it!

[leios]

Hey @berquist, quick question on the state of this PR. Obviously, no pressure to finish, but I just wanted to make sure it was still on the table.

[berquist]

I started work recently so have been busy. I'll take a look at it tomorrow and let you know when it's ready to merge.

[leios]

Of course no rush, just checking in

[berquist]

Can you do me a favor and try restarting Travis? I don't understand the sudden failure. https://travis-ci.org/algorithm-archivists/algorithm-archive/builds/432252148

[leios]

I'll be honest, I have no idea how to do that.

[berquist]

Is there a button labeled "Restart job" or something similar in the area where I have whitespace on the right?

[leios]

No, I see what you see

[june128]

@leios are you signed in to Travis?

[leios]

Yeah, alright. That was it. I logged in and could restart it. Sorry.

[leios]

This is black magic to me. Let's see if it works.