Closed jwflory closed 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
:
@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
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
@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.
This commit is a follow-up to discussion in
#rit-foss-admin
about how the site is deployed from the latestmaster
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 outmaster
branch. Keep dependencies installed in.bundle/
andvendor/
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 whycleanup: 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
andemail
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 believejekyll build
is run and no new files are committed to the repo. If this were true, it would mean.bundle/
andvendor/
would be committed tomaster
, 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