search

FOSSRIT / fossrit.github.io

Official website for Free and Open Source Software @ RIT MAGIC Center and FOSS academia
https://fossrit.github.io
Mozilla Public License 2.0
9 stars 12 forks source link

ci: Use Travis dpl v2 to deploy on GitHub Pages #117

Closed jwflory closed 4 years ago

jwflory commented 4 years ago

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

jwflory commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@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.