I am working to automate the deployment of my Jekyll site. This what the finished product will be:
I push a change from my local machine to my remote git repo.
A hook pulls the files into directory ABC.
guard notices the changes.
guard deletes the files in directory DEF.
guard uses jekyll to build the site to directory DEF.
I have everything set up except for #4. Does the guardfile allow for regular commands like rm? If not could I use guard-rake to call a rakefile that deleted the old content and then ran the Jekyll build?
Thanks.
Related
I have a Jekyll site that uses the jekyll-paginate plugin and is hosted by GitHub Pages, pretty standard.
Does anybody know of other solutions to handle pagination such that I could build two blogs from the same site at domain/blog1 and domain/blog2 using this solution, but also retain pagination?
Retaining the current pagination design is not a priority. Creative ideas that require redesign are welcome.
I know jekyll-paginate-multiple exists, but GitHub Pages does not support it natively, and I would have to maintain two repos to maintain the site code and build artifacts separately, which is not ideal.
Use any custom Plugin/Gem with your GitHub Pages hosted Jekyll blog
Here is how you CAN use any custom plugin on a GitHub Pages hosted website. I use this on my own blog so I'm 100% certain that it works. The basic idea is that you use TravisCI to build your custom Jekyll site on a staging branch and then push it automatically to your GitHubPages master branch that serves your website. Here comes the quick walkthrough:
a) you configure GitHub Pages to host from the docs folder of your master branch
b) you add and configure a staging branch to be the default branch of your repo, there is where you do all your local work, releases work through setting a git tag on this branch
c) you use _config.yml file to set your destination directory to docs
# _config.yml
destination: docs
d) to avoid build issues with Travis CI you can add Gemfile.lock to your .gitignore file and the docs folder to your local .git/info/exclude since you don't want to push them anymore. To exclude the docs folder from a local push is optional, but for me that works best. You also may need to delete the Gemfile.lock first and then let Travis CI pick the fitting versions for the selected Docker OS, otherwise you can run into version conflicts which can be pretty hard to fix.
e) to deploy with Travis CI into production a.k.a. your live site you add a .travis.yml file alike :
language: ruby
rvm:
- 2.6.3
install:
- bundle install
script:
- JEKYLL_ENV="production" bundle exec jekyll build
deploy:
provider: script
script: bash script/deploy.sh
skip_cleanup: true
on:
tags: true
branch: staging
branches:
only:
- staging
- /\d+\.\d+(\.\d+)?(-\S*)?$/
env:
global:
- NOKOGIRI_USE_SYSTEM_LIBRARIES=true
- secure: TRAVIS_SECRET_KEY_FOR_GITHUB_CREDENTIALS
sudo: false
cache: bundler
notifications:
email: false
g) script/deploy.sh looks somewhat like this:
#!/usr/bin/env bash
bundle install
JEKYLL_ENV="production" bundle exec jekyll build
git status
git add .
git commit -m"[skip travis] Automated build"
git remote set-url origin https://USERNAME:$PSW#github.com/YOUR_GIT_USER/YOUR_REPO.git
git push origin HEAD:master --force
e) to get your encrypted TRAVIS_SECRET_KEY_FOR_GITHUB_CREDENTIALS in .travis.yml with the used $PSW variable used in the deploy script, just follow the Encryption Key Doc
Once this configuration is done, you can use any Gem the same way as on localhost since the building part is not done by GitHub anymore but TravisCI.
Conclusion
You just work on staging and only let Travis CI push to your master branch. You use tags in the form 1.0.0 to deploy. All you need to do now is to add jekyll-paginate-multiple to your Gemfile and _config.yml and you are ready.
If anyone is interested in more details for those step, have a look at this Blog Post detailing the issue
If jekyll-paginate-multiple works in your context, you can use it on GitHub pages as well.
All you need to do is to copy
https://github.com/scandio/jekyll-paginate-multiple/blob/master/lib/jekyll-paginate-multiple.rb
into your repos _plugins folder and you are good to go.
I've got a line in my local .gitignore file to ignore a directory /user. I just don't want this directory to be changed in any way on the remote hosting version. People are using it to store files...
But when I push to openshift it deletes everything in that directory, instead of ignoring it. There is a mismatch now going on between git local and got remote. How can I reset what openshift is working form? Why are new files in that directory on the server being deleted, when I git push. I checked both the version of .gitignore on the local machine and on Openshift remote and they are the same. So it should ignore that directory. Damn it...
For persistent data storage, you should be using the OPENSHIFT_DATA_DIR directory. Check the Directory Environment Variables section at developers.openshift.com.
My heroku slug size is 389mb, so push is rejected. Now the Point is, if i deploy my same application on new domain (by using heroku create again), the slug size, i am seeing is just 200mb.. Why its different? Then I have tried this approach:
Approach 1: by deleting .git folder from my project directory, then again git init. and then deploying again on same heroku app.. It didn't make any differences!
Approach 2: By declaring .slugignore file in root of project folder. But its too not making any diff!
Approach 3: as per this site, https://github.com/heroku/heroku-repo
I have reset my repo like this,
heroku repo:reset -a appname
But, nothing happened!! What to do now? Can u guide me? Thnx.
As Heroku suggests:
Inspect your slug with heroku run bash and by using commands such as ls and du
Move large assets like PDFs or audio files to asset storage
Remove unneeded dependencies and exclude unnecessary files via .slugignore
Hey I was able to find the solution. Here is what i have done:
I have downloed Heroku Repo plugin from this site :https://github.com/heroku/heroku-repo just by this line:
heroku plugins:install https://github.com/heroku/heroku-repo.git
then I have just rebuilt my app by this command:
heroku repo:rebuild -a appname
This will empty the remote repository and push the repository up again, effectively triggering an app rebuild. and I got whole working app with original downsized (207mb) again. that's it.
I had a php app on heroku with the default buildpack (apache), and then decided to change it to the php-fpm + nginx buildpack (https://github.com/iphoting/heroku-buildpack-php-tyler/).
I issued the change command:
heroku config:set BUILDPACK_URL=https://github.com/iphoting/heroku-buildpack-php-tyler.git
And pushed with:
git push heroku master
The slug then compiles, but all the binaries fail to execute with "command not found", because PATH config variable which should be updated with bin/release isn't updated.
In comparison, when creating an app from scratch with this buildpack with
heroku create -b https://github.com/iphoting/heroku-buildpack-php-tyler.git
Everything runs as expected (and PATH is present and updated).
My assumption is that bin/release was not run after changing the config variable BUILDPACK_URL, and therefore the PATH variable isn't set.
In order to make the app work, I had to manually add the PATH config variable. Did anybody else ever encounter this? Is this the expected behavior? By my understanding, bin/release should always run after a slug compile?
EDIT: corrected the git url to the correct ".git" one
You are correct in your assumption, the addons and config_vars properties of bin/release are only taken from a buildpack on an app's first deploy. See https://devcenter.heroku.com/articles/buildpack-api#binrelease for more details.
Heroku is moving over to a new system for a buildpack to add config vars that will work beyond an app's first deploy: https://devcenter.heroku.com/articles/labs-dot-profile-d
If a buildpack copies a .profile.d/buildpack_name.sh into the app, that file will be sourced during application boot. This can be used to set up things like the PATH.
You probably have a Procfile in your app repository. If you have an existing Procfile, then bin/release won't overwrite its contents. Simply copy the appropriate lines (5-9) from https://github.com/iphoting/heroku-buildpack-php-tyler/blob/master/bin/release into your Procfile.
I'm using Heroku to host a Rails app, which means using Git to deploy to Heroku. Because of the "pure Git workflow" on Heroku, anything that needs to go upstream to the server has to be configured identically on my local box.
However I need to have certain configuration files be different depending on whether I'm in the local setup or deployed on Heroku. Again, because of the deployment method Heroku uses I can't use .gitignore and a template (as I have seen suggested many times, and have used in other projects).
What I need is for git to somehow track changes on a file, but selectively tell git not to override certain files when pulling from a particular repo -- basically to make certain changes one-way only.
Can this be done? I'd appreciate any suggestions!
You can have config vars persistently stored ON each heroku app's local setup so they do not have to be in your code at all! so the same code can run on multiple heroku sites but with different configuration. It very simple, easy, elegant...
It's the approach we used. (We used it for the SAME thing... we have multiple clones of the SAME app at Heroku, but we want only ONE source at github, in our dev local directory we do the PUSH to ORIGIN (github), then when we have it the way we like it, we CD to the prod local directory, which goes to the SAME github repository, and we ONLY PULL from GITHUB into this directory, never push (eg, all pushes to github come from our dev directory, the prod directory is just a staging area for the other heroku app.)
By having the different configs ON the different HEROKU sites (as explained below), the EXACT SAME CODE works on BOTH heroku sites.
So our workflow is: (the key is that BOTH directories point to SAME github repo)
cd myDEVdir
*....develop away....*
git add .
git commit -am "another day, another push"
git push origin *(to our SINGLE github repo)*
git push heroku *(test it out on heroku #1)*
cd ../myPRODdir
git pull *(grabs SAME code as used on other site *)
git push heroku *(now the SAME code runs on Heroku #2)*
that's it!
Now here's how you keep your site-specific config vars ON the heroku site:
http://docs.heroku.com/config-vars
on your local command line, for EACH of your two local directories, do:
$ heroku config:add FIRST_CONFIGVAR=fooheroku1
Adding config vars:
FIRST_CONFIGVAR => fooheroku1
$ heroku config:add SECOND_CONFIGVAR=barheroku1
Adding config vars:
SECOND_CONFIGVAR => barheroku1
to see the ones you have defined:
$ heroku config
FIRST_CONFIGVAR => fooheroku1
SECOND_CONFIGVAR => barheroku1
then cd to your other directory myPRODdir and do the SAME thing, only set the same remote heroku vars to fooheroku2 and barheroku2.
then in your rails app you simple refer to them like so:
a = ENV['FIRST_CONFIGVAR']
One app will read 'fooheroku1' the other app will read 'fooheroku2'
And finally, on your LOCAL directory myDEVdir, where you run in DEV mode, put the same config commands in your config/environment/development.rb file your 'dev' version of the config vars will be set to whatever they should be:
ENV['FIRST_CONFIGVAR'] = "foodev"
ENV['SECOND_CONFIGVAR'] = "bardev"
Easy, elegant. Thanks, Heroku!
Here are a few solutions:
1) If you want to ignore files only on heroku, use slugignore
2) If your changes are minor, stay DRY and use universal config files, inserting switches for server-specific behavior
if Rails.env == "production"
#production server code
elsif Rails.env == "development"
#development server code
else
#test server code
end
3) If your changes are major, write one config file and add a "smudge file" to config/initializers for each additional server. Basically, you would have separate files using the technique in (2).
4) If your changes are SWEEPING (unlikely), then maintain separate branches for each server.
5) This script can do exactly what you requested, but may be overkill.
I hope that helped.