Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Conversation

jwflory
Copy link
Member

@jwflory jwflory commented Mar 7, 2020

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

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>
@jwflory jwflory added improvement Improves on something that already exists quality assurance CI tests, unit tests, integration tests, any kind of testing labels Mar 7, 2020
@jwflory jwflory requested a review from a team March 7, 2020 16:42
@jwflory jwflory self-assigned this Mar 7, 2020
@jwflory jwflory added this to In progress in FOSS@MAGIC operations via automation Mar 7, 2020
@jwflory jwflory requested review from wilfriedE and kevinassogba and removed request for a team March 7, 2020 16:42
FOSS@MAGIC operations automation moved this from In progress to Waiting on external Mar 7, 2020
Copy link
Member

@ct-martin ct-martin left a 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

@jwflory
Copy link
Member Author

jwflory commented Mar 7, 2020

@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
Copy link
Member

@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
Copy link
Member

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 jwflory added the blocked Progress blocked by another task or issue label Mar 7, 2020
@jwflory
Copy link
Member Author

jwflory commented Mar 7, 2020

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

@jwflory jwflory closed this Mar 7, 2020
FOSS@MAGIC operations automation moved this from Waiting on external to Done Mar 7, 2020
@jwflory jwflory deleted the test/dplv2 branch March 7, 2020 22:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Progress blocked by another task or issue improvement Improves on something that already exists quality assurance CI tests, unit tests, integration tests, any kind of testing
Projects
Development

Successfully merging this pull request may close these issues.

None yet

2 participants