A Rakefile to simplify some operations on your jekyll websites.
Main features:
- Support to common tasks, such as building and previewing
- Compass compilation and watching
- Commands for checking links, publishing a post with a summary of the changes since last deployment
- URL substitutions, to simplify deployment to sub-URIs
- Management of different configurations (similar to Rails)
- Integration with
git
repositories: check there are no upstream changes before deploying; commit and push on publication - Deployment via
rsync
- Publishing to Github
Notice that Jekyll has introduced many new features since this Rakefile was first released. One, for instance, is support for compass compilation; another is improved documentation related to deployment on non-root URLs. This Rakefile is quite configurable in the functions it provides, so you might still find it useful, even if you are using some of the new features provided by Jekyll or even if you are deploying your website using Github pages.
1. Download this repository
2. Put the files in your jekyll website directory
3. If needed, change the values of the variables in _rake_configuration.yml
4. Start using it!
Note. The _rake_configuration.yml
can be safely deleted if you are using the default values or if you prefer to set the variables directly in the Rakefile.
Specify the deployment configuration in the _config_deploy.yml
file (see next section for details).
Then use the Rakefile as you wish. For instance:
rake create_post[,"A post"] rake preview rake deploy
Using relative URLs in a Jekyll site can be tricky. Think of a situation in which you are using the same layout for pages at different levels of nesting. Relative links in the layout will be resolved differently for pages at different levels of nesting and, thus, will work only for some of the pages, while failing for others. On the other hand, using absolute URLs in the layout might break the possibility of previewing a website, since absolute links might not solve correctly with respect to http://localhost:4000
. Moreover, if you want your website to remain portable, it is a good idea to make the deployment URL into a configuration variable, which can be set once and for all in a single location.
One way to address the issue mentioned above is using the baseurl
configuration variable, which can be used to make all URLs absolute and which can be overridden using a command-line argument when previewing. The point is that the value has to be set every time you run jekyll
.
This Rakefile adopts a similar solution. It allows users to define a variable, e.g. url
, and set this variable in a configuration file, e.g., _config_deploy.yml
to the URL to be used when deploying. The Rakefile
automatically uses the value read from _config_deploy.yml
when deploying and http://localhost:4000
when previewing. This ensures that URLs are correctly resolved in all the environments.
The approach, which is inspired by Rails, can be used to define different sets of variables for previewing and deploying. This is useful, for instance, when using JAPR, a plugin which allows to bundle assets. In fact, you might want to compile the assets only when deploying and leave them unbundled when debugging/previewing. This can be achieved setting the JAPR bundle
variable, which needs to be set to false
when previewing and to true
when deploying.
More in details, when running:
rake preview
, the Rakefile instructs Jekyll to read the_config.yml
file onlyrake deploy
(orrake build
), the Rakefile instructs Jekyll to read the content of both_config.yml
and_config_deploy.yml
This allows to provide specific settings for deployment, overriding those set in _config.yml
, if necessary.
Notice that you can also pass an optional argument to rake deploy
(rake build
), which specifies the environment you want to use. Thus, for instance:
rake build[testing]
will instruct Jekyll to read the content of both_config.yml
and_config_testing.yml
. Of course you can replacetesting
with any environment you prefer. This, for instance, allows you to mirror the same website on different machines or to test a deployment before actually making your website available.
If your website is hosted by a provider which supports rsync
, this Rakefile can deploy the website for you. More in details, a special variable deploy_dir
can be defined in _config_deploy.yml
, to specify the directory where the Jekyll site has to be deployed.
For instance, _config_deploy.yml
could look like:
baseurl: http://www.example.com/some/subdir deploy_dir: webuser@example.com:/some/directory
which instructs the Rakefile
to replace baseurl
with http://www.example.com/some/subdir
in your pages and copying the _site
files to @webuser@example.com:/some/directory@.
If your website is hosted on Github, you can use the deploy_github
task to publish the website.
The behavior is fairly simple: the task pushes the local gh_pages
branch to the corresponding remote branch. The main advantage with respect to directly invoking git push origin gh_pages
from the command line is some bookkeeping (e.g., checking the push command won’t be rejected and updating the _last_deploy
file).
If you are using git
to manage the sources of your website your code has to be in sync with the remote repository before publishing your website. If this is not the case, in fact, you will most likely deploy an old version of the repository, causing a regression.
The simplest solution to this issue is using Github pages or a custom post-commit
hook (once again, look at Jekyll’s documentation). In this case, in fact, the deployment of the website is managed directly by git after a successful push. This ensures that websites can be deployed only when the version being pushed builds upon the latest version committed on the repository and published.
However, if you cannot use Github pages or define a custom hook, this Rakefile can check the status of the default remote before deploying and, optionally, commit and push changes to the default remote after deploying a website. The first behavior (warning if you are trying to publish an old version of your repository) is set by default. If you want to commit and push on deploy, you need to set the variable $git_autopush
to true
in _rake_configuration.rb
.
The commands made available are:
rake build # Build for deployment (but do not deploy) rake check_links # Check links for site already running on localhost:4000 rake clean # Clean up generated site rake create_post[date,title,category,content] # Create a post rake deploy # Build and deploy to remote server via rsync rake deploy_github # Build and deploy to Github rake list_changes # Print the file changed since last deploy rake post_changes # Create a post listing all changes since last deploy rake preview # Preview on local machine (server with --auto)
- version 2.1 adds an (experimental) task to deploy to Github
- version 2.0 changes quite radically the behaviour, exploiting some of the changes made to Jekyll. The
Rakefile
does not mess up with_config.yml
anymore, but it expects a_config_deploy.yml
(or similar) file to specify the deployment directives. The value of$deploy_dir$ is now specified in_config_deploy.yml
; this allows to keep the configuration variables together; support multiple deployment configurations; give the_rake_configuration.rb
file up, if the default settings (compass, git check, …) are ok. The new git checks verify that the local repository is in sync with the remote and optionally pushes all changes to the remote after a commit.
If you do not put the following directive in your _config.yml
file:
exclude: ['Rakefile']
the Rakefile
will end up in your website. (It shouldn’t do any harm if you publish it.)
Distributed under the terms of the MIT License