-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: Use Travis dpl v2 to deploy on GitHub Pages #117
Conversation
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 Signed-off-by: Justin W. Flory <git@jwf.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jwflory please use a fork of the repo to test this before it gets merged
@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 |
@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 |
This commit is a follow-up to discussion in
#rit-foss-admin
about howthe site is deployed from the latest
master
branch. tl;dr: Thisswitches 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 staticcontent in CI job. If build is successful, clone repo and check out
master
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 thebuild. 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
andemail
for git commits use the current git commitauthor name and email, I am making a bet that the site is deployed
without adding commits to the target branch. I believe
jekyll build
isrun and no new files are committed to the repo. If this were true, it
would mean
.bundle/
andvendor/
would be committed tomaster
, as Iunderstand 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