This site is based on Octopress, which is in turn based on Jekyll, with a dash of Twitter Bootstrap added.

The develop branch is continuously deployed to a preview site. View dev site

The master branch is continuously deployed to production.

Please, feel free to make any contributions you feel will make SendGrid Documentation better.

Submit all pull requests to the develop branch

Before your pull request can be merged into the develop branch, you must submit a completed CLA.

Before you get started, SendGrid requires that a SendGrid Contributor License Agreement (CLA) or a SendGrid Company Contributor Licensing Agreement (CCLA) be filled out by every contributor to a SendGrid open source project.

Our goal with the CLA and CCLA is to clarify the rights of our contributors and reduce other risks arising from inappropriate contributions. The CLA also clarifies the rights SendGrid holds in each contribution and helps to avoid misunderstandings over what rights each contributor is required to grant to SendGrid when making a contribution. In this way the CLA and CCLA encourage broad participation by our open source community and help us build strong open source projects, free from any individual contributor withholding or revoking rights to any contribution.

SendGrid does not merge a pull request made against a SendGrid open source project until that pull request is associated with a signed CLA (or CCLA). Copies of the CLA and CCLA are available here.

You may submit your completed CLA or CCLA to SendGrid at [email protected]. SendGrid will then confirm you are ready to begin making contributions.

• Clone the repo.
• npm install to install build tools.
• bower install to install client-side dependencies (jQuery, bootstrap)
• bundle install to install required rubygems.
• Copy _config.sample.yml and name it _config.yml
• Set your root (if you're running locally it'll just be /) in _config.yml
• bundle exec rake preview
• Browse to localhost:4000

• The source files are in /source, and the generated files will be created in /public. They get overwritten or wiped out when the site is rebuilt.

• To rebuild the site: rake generate

The config is defined in _config.yml.

The only config variables you should need to know about are root, which is the root from which all links are calculated, and the folder_weights hash, which specifies the order that the folders should be displayed in the nav tree. Higher weights mean higher display priority (higher in the tree). You can also specify icons for folders with the folder_icons hash.

There's also a version number in the config.

• Clone the repo.

• Bring up development environment with Vagrant

    $ vagrant up
  

• Browse to http://localhost:4000

	$ vagrant ssh
	$ cd docs && bin/test

• The source files are in /source, and the generated files will be created in /public. They get overwritten or wiped out when the site is rebuilt.

• To rebuild the site: rake generate

The config is defined in _config.yml.

The only config variables you should need to know about are root, which is the root from which all links are calculated, and the folder_weights hash, which specifies the order that the folders should be displayed in the nav tree. Higher weights mean higher display priority (higher in the tree). You can also specify icons for folders with the folder_icons hash.

There's also a version number in the config.

The nav tree is generated by the plugin site_navigation.rb. It is essentially a recursive traversal of all the folders and pages in the Source folder that generates a hierarchical tree, sorted by folder weight and page weight.

Breadcrumbs are generated by the breadcrumbs.rb plugin.

You can write pages in markdown, HTML, or HAML. They all get converted to HTML when the site is generated.

Pages have a block of YAML at the top that sets a few options. They are pretty self explanatory; here's an example

---
layout: page
weight: 0
title: Docs Home
icon: icon-home
showTitle: false
navigation:
  show: true
---

Weights are same as the folder weights - the higher numbers move higher up the tree. Icons are based on the CSS icon class names from Twitter Bootstrap. showTitle and navigation["show"] both default to true if not specified.

Various fields pertinent to SEO can be controlled through the YAML frontmatter. Here's an example:

---
seo:
  title: Really Great Documentation - SendGrid Documentation | SendGrid
  override: true
  description: This is some really great documentation! I hope you like it!
  canonical: http://sendgrid.com/docs/really-great-docs
---

By default <title> tags follow the template {Page Title} {Site Title}. However the page title can be changed for the purpose of the tag by using seo["title"]. seo["override"] will override the entire template, instead making the title tage {seo["title"]}. description and canonical change their respective tags.

There are some custom plugins (look in the plugins folder) that define new liquid blocks for use in pages.

You can create anchor tags that will have named anchors generated for them automatically with links on hover. The parameter is the wrapping element to use.

{% anchor h2 %}
Some Anchor Text
{% endanchor %}

Similarly you can create info and warning blocks:

{% info %}
Some info for a breakout block.
{% endinfo %}

{% warning %}
...And a warning breakout.
{% endwarning %}

If you are working on API reference docs, you can generate XML and JSON nav tabs and the corresponding example calls and responses like so:

{% apiexample identifier GET http://some.endpoint.url var1=stuff&var2=junk %}
  {% response json %}
{ "foo": "bar" }
  {% endresponse %}

  {% response xml %}
<foo>bar</foo>
  {% endresponse %}
{% endapiexample %}

The parameters for the apiexample block are: unique identifier, HTTP method, the url (excluding .json or .xml extension), and the data payload in querystring format.

JavaScript and CSS are minified and combined. The files to be packaged and their orders are specified in _includes/head.html and CssMinify.yml. Preprocessing and options can be specified via _plugins/jekyll_asset_pipeline.rb.