Automatically build book and deploy to a repo

[berquist]

If you turn on Travis continuous integration (free), you can test code in a remote container and do other neat stuff, like deploy documentation...or a book.

1. "Test" the repository by making sure the book builds. CI runs automatically at every update for every PR, and every merge to master. Fixed the broken build #281 would have been caught before merging.
2. If the book builds successfully, and this is a merge to master, push the book to a remote repo. No more need to update manually.

1 can exist without 2, so if you don't like it, that part can be removed. The results for my build are at https://travis-ci.com/berquist/algorithm-archive. Signing up for Travis CI is relatively easy, but if you want point 2, here is the extra work required. Everything below here is about automatically deploying the book.

1. On GitHub, request a Personal Access Token, with repo scope. Instructions here, but can be done entirely from the browser. Keep the token somewhere safe, because you can't look at it again, and do not give it to anyone else.

2. The deploy script requires that some environment variables be entered into Travis. At your Travis repo page,
   
   click "More options" then "Settings", then scroll down. These are mine for testing. The repo is https://github.com/berquist/algorithm_archive_build/commits/master and the website is https://berquist.github.io/algorithm_archive_build/.
   
   Your non-secret environment variables would be

• GH_USER: algorithm-archivists
• GH_REPO_NAME: algorithm-archivists.github.io
• DOCS_BRANCH_NAME: master
• GH_TOKEN: copy-paste the PAT here, and don't display it.

[Butt4cak3]

Not a bad idea. If there is one thing we should automate then it's probably testing whether a PR breaks the build or not. Automatic deployment is something we will have to talk about first, but I'm definitely in favor of it.

I read the scripts and couldn't find anything really wrong with them. Your shell scripts are definitely better than mine. I don't know any Travis specifics, though.

PS: I want to mention how much I appreciate the quality PR. It has screenshots and everything! I hope you'll stick around for a while. :)

[leios]

Yup. This is a geed feature. Thanks! I don't know if I am qualified to review it though.

[berquist]

Thanks. There is another CI provider, CircleCI, that may or may not be better. If you leave this open for a little while, it'll give me a chance to try it out.

[june128]

I agree, if the code gets verified by someone of our team and it is alright, I don't see any problems with this PR.
Both 1 and 2 seem useful and I vote for including them both. Thanks for this cool PR!

[berquist]

Five minutes messing with CircleCI showed it isn’t appropriate to switch from Travis.

…

On Sat, Jul 21, 2018 at 10:50 AM Eric Berquist ***@***.***> wrote: Thanks. There is another CI provider, CircleCI, that may or may not be better. If you leave this open for a little while, it'll give me a chance to try it out. — You are receiving this because you are subscribed to this thread. 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%2F284%23issuecomment-406801494&data=01%7C01%7Cerb74%40pitt.edu%7Ca5efbe933d6544a42cf408d5ef19443b%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=9ZkxXcvov2bTPsUqw9YOh1dgqzpiO3d7IJjW6anYFzg%3D&reserved=0>, or mute the thread <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAsaE6xWIoYs13Dv2FMvIpHmatVCypirks5uIz-lgaJpZM4VZeuM&data=01%7C01%7Cerb74%40pitt.edu%7Ca5efbe933d6544a42cf408d5ef19443b%7C9ef9f489e0a04eeb87cc3a526112fd0d%7C1&sdata=ocUbjamw3yzWvYqvq82ljpGbx51zFIb2wFvSfJsEvt0%3D&reserved=0> .

[leios]

I'm fine with sticking to Travis. I think it's relatively standard. If it works, it works.

[leios]

Hey @berquist , A few quick questions from someone who is completely new to this:

1. I created a token for my personal profile and used that to authenticate the organizational repo, is that alright? I don't think I can create a token for the organization, itself.

2. This will not retroactively affect already submitted PR's, right?

I think I got things set up on my end, so if no one is against the idea, I might merge the PR soon and see if it works.

[berquist]

1. I think so. I haven't deployed this to the one organization I'm a part of, so I've only done a personal token for personal repos. Looking at my org settings, there isn't even an option to make an org token. The worst thing that will happen is you'll fail at cloning the book repo, and it will say the build failed, which isn't a big deal. Looking at the Travis log should be informative enough for debugging.

2. It will not. Further commits to any existing PRs will trigger a build but not deploy, and merging to master will build and deploy.

[leios]

Since there doesn't seem to be further discussion here and this is a good change, I will go ahead and merge it.

[leios]

Hey, I screwed up. I didn't know this would push to algorithm-archivists.github.io. I thought it would only merge to the algorithm-archive. We reverted the changes because the site went down, but I am not entirely sure why that happened

I definitely want CI in this repo. It makes a lot of sense. How do we go about debugging this and figuring out what went wrong?

[june128]

So we basically only want 1 and not 2.

[berquist]

I should have said "this will deploy to algorithm-archivists.github.io" and not been vague. So, I will back out part 2.

However, I only partially understand why it didn't work. Part of it is that I didn't handle the CNAME file properly, which is why the redirect didn't work. But a bunch of other things (source code files in particular) were also deleted.

I don't know if the missing CNAME file is the only reason why it didn't work. I'll compare my personal built with the actual site repo.

[june128]

@berquist We're currently discussing the topic, so we might go with the full scope of the PR. It can also be, that Leios configured Travis CI wrong, which might have caused errors, but I'm unsure about that.

[leios]

So after some discussion, I think we have agreed the automatic deployment is worth it. I just for some reason completely misunderstood. Looking at it, it's clear. I think the reason this didn't work is because I didn't provide my PAT for the algorithm-archivists.github.io repo, but instead for the algorithm-archive, only.

Do you think it would work if I gave the pat to the algorithm-archivists.github.io instead?

[berquist]

No, I looked at the Travis log and it worked. There is a problem with my understanding of what extra bits were in the site repo. Even cloning the book repo would have failed without the PAT.

I should say that once you generate the PAT, it gives Travis access to do anything you can do as a GitHub user, up to the limit of those checkboxes when you were generating it. You have push access to algorithm-archivists.github.io? So does anyone else (or anything) with the token. That's why it needs to be kept a secret.

[leios]

I have push access, but the master branch is protected. Does that matter?

[PudottaPommin]

yes when it does force push

[leios]

So this probably would have worked if the branch was not protected?

[berquist]

Rather than me guess, I will try it out...give me a few minutes.

[leios]

No rush, take your time. We know what we want now. It's now just a matter of figuring out what went wrong and fixing it.

Sorry for making this super frustrating.

[PudottaPommin]

maybe worth looking at https://docs.travis-ci.com/user/deployment/pages/#setting-the-github-token ?

[berquist]

That's very interesting. I didn't know that existed. If a non-force-push with the custom script doesn't work, it could be rewritten using that...or maybe it should anyway.