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

Add continuous integration to support i18n plugin #66

Closed
ajmas opened this issue Nov 8, 2017 · 9 comments
Closed

Add continuous integration to support i18n plugin #66

ajmas opened this issue Nov 8, 2017 · 9 comments

Comments

@ajmas
Copy link
Collaborator

ajmas commented Nov 8, 2017

Add continuous integration to support the i18n plugin, required to allow completing issue #1.

Proposal:

  • Use Travis
  • Limit to branches with .travis.yml file
  • Generated code from gh-pages branch goes into gh-page-gen branch, which will be set as the branch GitHub Pages will show
@ajmas
Copy link
Collaborator Author

ajmas commented Nov 8, 2017

Have created https://travis-ci.org/nodeschool/montreal , but still requires configuration. Can anyone who has commit access to this repo tell me if you are able to view the settings?

Also see https://jekyllrb.com/docs/continuous-integration/travis-ci/ for configuration guide.

@matchai
Copy link
Collaborator

matchai commented Nov 8, 2017

Looks like it's all configured correctly by default!
All we need is the travis.yml in the repo to get going.

Should I go ahead and make a PR with the travis.yml, or would you like to do the honors?

@ajmas
Copy link
Collaborator Author

ajmas commented Nov 8, 2017

I am looking at it now. Just doing a test build. Though if you have more time go for it. The one thing not resolved on my end is where to put the generated code.

@matchai
Copy link
Collaborator

matchai commented Nov 8, 2017

I'll see if I've got time this evening to get around to it.
As for the generated code, we would need it to be generated into the root of the project for gh-pages to see them, so we'll have to modify the jekyll config to have the source files in a "source" folder and the generated output in the root of the project.

@matchai
Copy link
Collaborator

matchai commented Nov 8, 2017

Alternatively we can have a branch for the source files and the generated output deployed to gh-pages. (seems like the cleanest solution)

@ajmas
Copy link
Collaborator Author

ajmas commented Nov 8, 2017

If we can do a separate branch for generated content, then it would avoid mixing source and generated code? Also avoid the risk of recursive builds.

@ajmas ajmas closed this as completed Nov 8, 2017
@ajmas ajmas reopened this Nov 10, 2017
@ajmas
Copy link
Collaborator Author

ajmas commented Nov 10, 2017

This gist describes how to deploy to a github project: https://gist.github.com/domenic/ec8b0fc8ab45f39403dd

@ajmas
Copy link
Collaborator Author

ajmas commented Nov 10, 2017

@matchai I am out of time for the next few days, but you can see in Travis the failure. If you have time could you look the failure with the openssl step? I think that is all that is missing.

@ajmas ajmas closed this as completed in 9dc172f Nov 13, 2017
ajmas added a commit that referenced this issue Nov 13, 2017
@ajmas
Copy link
Collaborator Author

ajmas commented Nov 13, 2017

Reopening, since I just noticed we are limited to using gh-pages or master for gh-pages. It looks like I will need to reconfigure and change the source branch, I am thinking maybe something like gh-pages-src?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants