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 deploy-gh-pages command which builds site and publishes to Github Pages #6

Closed
KyleAMathews opened this Issue Jun 22, 2015 · 34 comments

Comments

Projects
None yet
6 participants
@KyleAMathews
Contributor

KyleAMathews commented Jun 22, 2015

UPDATE: We'll be using https://www.npmjs.com/package/gh-pages

@KyleAMathews

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Jul 22, 2015

Contributor

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).

Contributor

KyleAMathews commented Jul 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Jul 22, 2015

Contributor

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.

Contributor

KyleAMathews commented Jul 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Jul 22, 2015

Contributor

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.

Contributor

KyleAMathews commented Jul 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@gesposito

gesposito Sep 14, 2015

Contributor

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

Contributor

gesposito commented Sep 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Sep 14, 2015

Contributor

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

Contributor

KyleAMathews commented Sep 14, 2015

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

@gesposito

This comment has been minimized.

Show comment
Hide comment
@gesposito

gesposito Sep 15, 2015

Contributor

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).

Contributor

gesposito commented Sep 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@kennethormandy

kennethormandy Sep 28, 2015

Contributor

@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.

Contributor

kennethormandy commented Sep 28, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Sep 28, 2015

Contributor

@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?

Contributor

KyleAMathews commented Sep 28, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@matteodem

matteodem Oct 21, 2015

+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.

matteodem commented Oct 21, 2015

+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 comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Oct 21, 2015

Contributor

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.
Contributor

KyleAMathews commented Oct 21, 2015

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

This comment has been minimized.

Show comment
Hide comment
@matteodem

matteodem Oct 21, 2015

perfect, thanks!

matteodem commented Oct 21, 2015

perfect, thanks!

@matteodem

This comment has been minimized.

Show comment
Hide comment
@matteodem

matteodem Oct 22, 2015

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

matteodem commented Oct 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@kennethormandy

kennethormandy Oct 22, 2015

Contributor

@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).

Contributor

kennethormandy commented Oct 22, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@matteodem

matteodem Oct 22, 2015

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

matteodem commented Oct 22, 2015

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

@KyleAMathews

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Oct 22, 2015

Contributor

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.

Contributor

KyleAMathews commented Oct 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Oct 22, 2015

Contributor

And surge is definitely the easy solution for now :)

Contributor

KyleAMathews commented Oct 22, 2015

And surge is definitely the easy solution for now :)

@KyleAMathews

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Oct 22, 2015

Contributor

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

// 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;
}
};

Contributor

KyleAMathews commented Oct 22, 2015

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

// 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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Nov 22, 2015

Contributor

@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

Contributor

KyleAMathews commented Nov 22, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Nov 22, 2015

Contributor

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

Contributor

KyleAMathews commented Nov 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@matteodem

matteodem Nov 22, 2015

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

matteodem commented Nov 22, 2015

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

@kennethormandy

This comment has been minimized.

Show comment
Hide comment
@kennethormandy

kennethormandy Nov 22, 2015

Contributor

@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.

Contributor

kennethormandy commented Nov 22, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Nov 23, 2015

Contributor

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

Contributor

KyleAMathews commented Nov 23, 2015

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

@KyleAMathews

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Feb 25, 2016

Contributor

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.

Contributor

KyleAMathews commented Feb 25, 2016

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

This comment has been minimized.

Show comment
Hide comment
@gesposito

gesposito Feb 28, 2016

Contributor

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

Contributor

gesposito commented Feb 28, 2016

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

@SachaG

This comment has been minimized.

Show comment
Hide comment
@SachaG

SachaG Aug 22, 2016

Contributor

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?

Contributor

SachaG commented Aug 22, 2016

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

This comment has been minimized.

Show comment
Hide comment
@SachaG

SachaG Aug 22, 2016

Contributor

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

Contributor

SachaG commented Aug 22, 2016

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

@KyleAMathews

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Aug 22, 2016

Contributor

👍😉👊
On Mon, Aug 22, 2016 at 1:22 AM Sacha Greif notifications@github.com
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
.

Contributor

KyleAMathews commented Aug 22, 2016

👍😉👊
On Mon, Aug 22, 2016 at 1:22 AM Sacha Greif notifications@github.com
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

This comment has been minimized.

Show comment
Hide comment
@SachaG

SachaG Aug 23, 2016

Contributor

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

Contributor

SachaG commented Aug 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Aug 23, 2016

Contributor

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

Contributor

KyleAMathews commented Aug 23, 2016

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

@SachaG

This comment has been minimized.

Show comment
Hide comment
@SachaG

SachaG Aug 23, 2016

Contributor

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

Contributor

SachaG commented Aug 23, 2016

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

@KyleAMathews

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Aug 23, 2016

Contributor

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 notifications@github.com
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
.

Contributor

KyleAMathews commented Aug 23, 2016

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 notifications@github.com
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
.

@SachaG

This comment has been minimized.

Show comment
Hide comment
@SachaG

SachaG Aug 23, 2016

Contributor

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 :)

Contributor

SachaG commented Aug 23, 2016

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 :)

@andrewdc

This comment has been minimized.

Show comment
Hide comment
@andrewdc

andrewdc Jan 24, 2017

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!!

andrewdc commented Jan 24, 2017

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

This comment has been minimized.

Show comment
Hide comment
@KyleAMathews

KyleAMathews Jan 25, 2017

Contributor

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

Contributor

KyleAMathews commented Jan 25, 2017

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

gosseti pushed a commit to gosseti/gatsby that referenced this issue Jun 5, 2017

Merge pull request #6 from mef/patch-1
 Add history as top-level dependency

mdreizin added a commit to mdreizin/gatsby that referenced this issue Jul 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment