Add deploy-gh-pages command which builds site and publishes to Github Pages

[gatsbyjs]

Add deploy-gh-pages command which builds site and publishes to Github Pages

[SachaG]

Hmm, would that work? If I understand things correctly, the CNAME file is being removed by gh-pages, not by Gatsby itself?

[SachaG]

Oh of course! Since the CNAME has to end up at the root of the gh-pages branch, I stupidly put it at the root of my master branch too. But it should be in /public, that makes sense :)

[KyleAMathews]

Algorithm is:

1. Clone site to tmp directory and change origin to github.
2. Create orphan gh-pages branch (if one doesn't already exist)
3. Build site to the cloned repo.
4. Commit and push (just use a generic commit message?)

Orphan branches have their own history.

Using a cloned git repo avoids having to switch to the gh-pages branch on the main repo which deletes all files/directories not under git (e.g. node_modules).

[KyleAMathews]

Need to auto-prefix links with name of repo. Need way to disable this in config so people pointing a domain at github site can disable this.

[KyleAMathews]

Or probably the simplest way to do this is to put the prefix value in the config. Check if the config key is there, if not, ask for it.

[gesposito]

Found these (limited to Node)
https://github.com/felixge/node-romulus/blob/master/lib/deploySite.js
author could be pinged for contribution, or better

https://github.com/koistya/git-push
external module

[KyleAMathews]

Oh nice finds! Yeah, the node-romulus script looks almost perfect. We could copy that pretty easily and tweak it to our needs.

[gesposito]

Also:
https://github.com/lukekarrys/git-directory-deploy
that would be as easy as:

"scripts": {
    "deploy": "git-directory-deploy --directory _dist --branch gh-pages"
}

It also accept a repo url so it could push to any git based provider (i.e. Azure, Heroku, GitHub Pages as git-push).

[kennethormandy]

@KyleAMathews Hey! Really nice work on this project so far, I am looking forward to giving it a more thorough try.

Would you be interested in a pull request that adds Surge as the deployment tool? Surge can be installed as a devDependency with npm, so Gatsby sites could be published with one command:

npm install --save-dev surge
surge ./public my-gatsby-blog.surge.sh

This is what React projects Spectacle and hjs-webpack do.

You can also use custom domains for free, and catch-all URLs for client-side routing with React. Let me know what you think! Either way, excited to see more React + static stuff out there.

[KyleAMathews]

@kennethormandy hey adding support for Surge would be great!

I'm actually speccing out a plugin system for Gatsby right now. Surge would be a great "publish" plugin. There could be a number of these like publishing to Surge, Amazon S3, Github, etc.

So to publish to Surge, the cli command would be something like gatsby build --publish surge. Within your Gatsby config file, there'd probably be a surge key with your Surge auth and other details.

Could you create a quick issue about supporting Surge and other publish plugins to keep track of this?

[matteodem]

+1 for this.

Also was interested if there's any docs on how to use gatsby for github pages. I used the documentation starter and am about to try this out. Any hint into the right direction would be helpful.

[KyleAMathews]

This issue is about automating publishing to github pages. It's pretty easy to do manually in the meantime.

Steps are:

1. Build your Gatsby site.
2. Copy files from public into another directory e.g. /tmp/my-site/
3. [The first time doing this] create the gh-pages branch https://help.github.com/articles/creating-project-pages-manually/
4. Switch to the gh-pages branch. Copy back your built site.
5. Add files, commit, and push.

[matteodem]

perfect, thanks!

[matteodem]

I just tried this and the steps do not work, as the starter template generates absolute link paths. See http://matteodem.github.io/meteor-easy-search/, branch is https://github.com/matteodem/meteor-easy-search/tree/gh-pages

[kennethormandy]

@matteodem I’m hoping I’m able to work on a built-in deployment integration using Surge per #52, but if you want to try that as an alternative in the meantime:

npm install -g surge
surge ./path/to/gatsby-build

This will prompt you to create an account and publish for free. You could also save Surge as a devDependency and add it as a run script for your package.json, and even run it on every push like with GitHub Pages if you want (but without all the branch switching).

[matteodem]

oh, that looks great thanks! I'll have a look this weekend.

[KyleAMathews]

Yeah... it's a bit hacky right now getting URLs to work. I think the right solution is to have a link function for which you can set a link prefix in your config so when you build for Github all the links turn out right.

[KyleAMathews]

And surge is definitely the easy solution for now :)

[KyleAMathews]

LOL, actually my former self agrees with my current self. I already added that link function

gatsby/lib/isomorphic/gatsby-helpers.js

Lines 6 to 14 in 852ae4b

	// Prefix links for Github Pages.
	// TODO make this generic for all prefixing?
	exports.link = function(link) {
	if ((typeof __GH_PAGES__ !== "undefined" && __GH_PAGES__ !== null) && __GH_PAGES__ && (config.ghPagesURLPrefix != null)) {
	return config.ghPagesURLPrefix + link;
	} else {
	return link;
	}
	};

[KyleAMathews]

@matteodem the 0.7 release I did earlier improved the support for gh-pages a ton. You should be able to create a new docs or blog site and push it to github pages and it'll work.

See the release notes https://github.com/gatsbyjs/gatsby/releases/tag/v0.7.0

[KyleAMathews]

Somehow I missed this npm package when looking around before https://www.npmjs.com/package/gh-pages. Just tested the global version and it works beautifully.

I'm thinking now we'll just add deploy support for as targets as people want to support. For starters github pages and surge. The commands will be something like gatsby deploy gh-pages and gatsby deploy surge

One thought is to add deployment as a option for building e.g. gatsby build --deploy gh-pages. My problem with this though is I feel it conflates building and deploying too much as often you'll want to build locally just to make sure the built version of the site is working as expected before deploying. Thoughts?

/cc @kennethormandy

[matteodem]

thanks for the update will try it out in the next days!

[kennethormandy]

@KyleAMathews Since I last updated you on this, we made it possible to build Surge into a CLI easily. Here are the docs right now for using Surge and Commander together.

I think you would still want the build command separate. With Surge, you can run the build step automatically as part of the deployment, and then show an error if necessary if the compilation fails for some reason, and otherwise finish the deploy. We have a more thorough Commander example doing exactly that which I can pass along as well.

[KyleAMathews]

👍 thanks for the link @kennethormandy, the integration looks like it'll be very easy.

[KyleAMathews]

I'm going to say deploy plugins are out of scope. It's easy enough to install gh-pages and add an npm script which runs gatsby build and then gh-pages.

[gesposito]

Just for reference, I found this useful gist
https://gist.github.com/cobyism/4730490

[SachaG]

It's easy enough to install gh-pages and add an npm script which runs gatsby build and then gh-pages.

Is there any tutorial that provides more info about this? Or maybe it could be added to the documentation?

[SachaG]

Oh, looks like that this is already part of the default boilerplate as npm run deploy. My bad!

[KyleAMathews]

👍😉👊
On Mon, Aug 22, 2016 at 1:22 AM Sacha Greif [email protected]
wrote:

Oh, looks like that this is already part of the default boilerplate as npm
run deploy. My bad!

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEVhzz4kzhr7X3R7FCnTbfmwSYv9TG_ks5qiVxKgaJpZM4FJXSc
.

[SachaG]

Actually this isn't quite usable in its current state because it removes the CNAME file every time you deploy, thus breaking your custom domain:

tschaub/gh-pages#74

I'll submit a PR to fix this once gh-pages itself is fixed:

tschaub/gh-pages#113

[KyleAMathews]

Perhaps just copy the CNAME file into public using the postBuild hook?

[KyleAMathews]

As I understand, gh-pages just copies directly over from the src directory.
So if the CNAME file is in public it'll end up in the gh-pages branch. That
being said, I could be wrong as I haven't tried to solve this issue.
On Mon, Aug 22, 2016 at 6:54 PM Sacha Greif [email protected]
wrote:

Hmm, would that work? If I understand things correctly, the CNAME file is
being removed by gh-pages, not by Gatsby itself?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAEVhxyQpFlM6SULMJN08We7eatANaDRks5qilLkgaJpZM4FJXSc
.

[andrewdc]

I just ran into this problem and tried to sum it up. Let me know if this kinda sorta covers the bases?

http://andrewdc.com/ghpages-gatsby-and-domains/

Thanks all for the solutions above!!

[KyleAMathews]

@andrewdc looks great! Thanks for writing up your solution!