mirror of
https://github.com/gohugoio/hugo.git
synced 2024-05-11 05:54:58 +00:00
doc: Merge commit '2c0d1ccdcd95de0bddeb39dca2e4d08f0d8056d7'
This commit is contained in:
@@ -27,7 +27,7 @@ notesforauthors:
|
||||
|
||||
The spoiler is that you can deploy your entire website with a command that looks like the following:
|
||||
|
||||
```bash
|
||||
```
|
||||
hugo && rsync -avz --delete public/ www-data@ftp.topologix.fr:~/www/
|
||||
```
|
||||
|
||||
@@ -39,15 +39,13 @@ If it is not done yet, we will make an automated way to SSH to your server. If y
|
||||
|
||||
First, install the ssh client. On Debian/Ubuntu/derivates, use the following command:
|
||||
|
||||
{{% code file="install-openssh.sh" %}}
|
||||
```bash
|
||||
{{< code file="install-openssh.sh" >}}
|
||||
sudo apt-get install openssh-client
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
Then generate your ssh key by entering the following commands:
|
||||
|
||||
```bash
|
||||
```
|
||||
~$ cd && mkdir .ssh & cd .ssh
|
||||
~/.ssh/$ ssh-keygen -t rsa -q -C "For SSH" -f rsa_id
|
||||
~/.ssh/$ cat >> config <<EOF
|
||||
@@ -61,7 +59,7 @@ EOF
|
||||
|
||||
Don't forget to replace the `HOST` and `USER` values with your own ones. Then copy your ssh public key to the remote server:
|
||||
|
||||
```bash
|
||||
```
|
||||
~/.ssh/$ ssh-copy-id -i rsa_id.pub USER@HOST.com
|
||||
```
|
||||
|
||||
@@ -78,13 +76,13 @@ And you've done it!
|
||||
|
||||
We will put the first command in a script at the root of your Hugo tree:
|
||||
|
||||
```bash
|
||||
```
|
||||
~/websites/topologix.fr$ editor deploy
|
||||
```
|
||||
|
||||
Here you put the following content. Replace the `USER`, `HOST`, and `DIR` values with your own:
|
||||
|
||||
```bash
|
||||
```
|
||||
#!/bin/sh
|
||||
USER=my-user
|
||||
HOST=my-server.com
|
||||
|
@@ -47,33 +47,27 @@ All the work for setting up a Hugo project and using this guide is done via the
|
||||
|
||||
First, create your new Hugo website using the [`hugo new site` command][basicusage] and change into the newly created directory for the project. In this guide, we are calling our new project `hugo-wercker-example`:
|
||||
|
||||
{{% code file="hugo-new-site.sh" %}}
|
||||
```bash
|
||||
{{< code file="hugo-new-site.sh" >}}
|
||||
hugo new site hugo-wercker-example
|
||||
cd hugo-wercker-example
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
We will use the [Herring Cove theme][] by first cloning the theme into the `themes` directory.
|
||||
|
||||
{{% code file="clone-herring-cove-theme.sh" %}}
|
||||
```bash
|
||||
{{< code file="clone-herring-cove-theme.sh" >}}
|
||||
cd themes
|
||||
git clone https://github.com/spf13/herring-cove.git
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
Cloning the project from the command line will conflict with our own version control. So, we need to remove the external git configuration that came with the clone of Herring Cove:
|
||||
|
||||
{{% code file="remove-herring-cove-git.sh" %}}
|
||||
```bash
|
||||
{{< code file="remove-herring-cove-git.sh" >}}
|
||||
rm -rf herring-cove/.git
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
We need content for Hugo to build. Let's add a quick `/about` page:
|
||||
|
||||
```bash
|
||||
```
|
||||
hugo new about.md
|
||||
```
|
||||
|
||||
@@ -83,15 +77,13 @@ The preceding example for the about page leverages archetypes to scaffold a new
|
||||
|
||||
Now you can edit `contents/about.md` in your text editor of choice, but this is not necessary for the purposes of this guide. Running the following command will build your Hugo site into the `public` directory. We have added `undraft` to ensure that the example page is no longer in draft mode:
|
||||
|
||||
{{% code file="hugo-build-undraft.sh" %}}
|
||||
```bash
|
||||
{{< code file="hugo-build-undraft.sh" >}}
|
||||
hugo undraft content/about.md
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
Once the website is build, t's a good idea to run the following command to start a local server and ensure you're changes have been implemented:
|
||||
|
||||
```bash
|
||||
```
|
||||
hugo server --theme=herring-cove
|
||||
```
|
||||
|
||||
@@ -103,29 +95,25 @@ If everything is fine, you should see something similar to the image below when
|
||||
|
||||
Adding Git to your project is done by running the `git init` command from the root directory of your project.
|
||||
|
||||
```bash
|
||||
```
|
||||
git init
|
||||
```
|
||||
|
||||
Running `git status` at this point will show you the following entries: the `config.toml` file, the `themes` directory, the `contents` directory, and the `public` directory. However, we don't want the `public` directory version controlled because Wercker is responsible for generating the finished website later on. Therefore, we'll add a `.gitignore` file to our project that will exclude the `/public` directory from being tracked by Git:
|
||||
|
||||
{{% code file="gitignore.sh" %}}
|
||||
```bash
|
||||
{{< code file="gitignore.sh" >}}
|
||||
echo "/public" >> .gitignore
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
Wercker might complain when we try to build the site later on because we currently do not have any static files outside of the `themes` directory. We simply have to add *any* file to the static folder to prevent Wercker from complaining. To keep this guide simple, let's add a `robots.txt`. The following command creates the file in `/static`. The contents of the `robots.txt` lets search engines know they have full access to crawl the published website:
|
||||
|
||||
{{% code file="addrobotstxt.sh" %}}
|
||||
```bash
|
||||
{{< code file="addrobotstxt.sh" >}}
|
||||
echo "User-agent: *\nDisallow:" > static/robots.txt
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
Now we need to add (i.e., [stage [see Git documentation]][gitbasics]) and commit all of our changes in the repository into Git:
|
||||
|
||||
```bash
|
||||
```
|
||||
git commit -a -m "Initial commit"
|
||||
```
|
||||
|
||||
@@ -135,12 +123,10 @@ Now we need to create a new repository on GitHub. Once you are signed in to GitH
|
||||
|
||||
We then choose a name for the project (`hugo-wercker-example`). When clicking on create repository GitHub displays the commands for adding an existing project to the site. The commands shown below are the ones used for this site, if you're following along you will need to use the ones shown by GitHub. Once we've run those commands the project is in GitHub and we can move on to setting up the Wercker configuration. Be sure to replace `YourUserName` with your GitHub account/username:
|
||||
|
||||
{{% code file="setup-gh-repo.sh" %}}
|
||||
```bash
|
||||
{{< code file="setup-gh-repo.sh" >}}
|
||||
git remote add origin git@github.com:YourUsername/hugo-wercker-example.git
|
||||
git push -u origin master
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
![][2]
|
||||
|
||||
@@ -230,8 +216,7 @@ We're not going to use any of the advanced features of Hugo-Build in this guide.
|
||||
The docs are a work in progress. As such, the `version` represented in this guide may not represent the version you've been using for local development. Be sure to use the appropriate Hugo version for your build step.
|
||||
{{% /warning %}}
|
||||
|
||||
{{% code file="wercker-build-step.yml" %}}
|
||||
```yaml
|
||||
{{< code file="wercker-build-step.yml" >}}
|
||||
box: debian
|
||||
build:
|
||||
steps:
|
||||
@@ -239,17 +224,14 @@ build:
|
||||
version: "0.17"
|
||||
theme: herring-cove
|
||||
flags: --buildDrafts=true
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
We can conclude this first step by pushing our `wercker.yml` to our GitHub repository and then seeing the magic at work within Wercker's interface.
|
||||
|
||||
{{% code file="push-wecker-to-gh.sh" %}}
|
||||
```bash
|
||||
{{< code file="push-wecker-to-gh.sh" >}}
|
||||
git commit -a -m "Add wercker.yml"
|
||||
git push origin master
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
If completed and successful, a green check mark should appear in the commit column of your first build. However, this is only the build step. We still need to deploy the website to our free hosting on GitHub Pages. If you would like more details about the build, you can click the commit hash.
|
||||
|
||||
@@ -259,8 +241,7 @@ If completed and successful, a green check mark should appear in the commit colu
|
||||
|
||||
In order to deploy to GitHub Pages, we need to add a deploy step to our `wercker.yml`. We are going to add `lukevevier/gh-pages`, the most popular GitHub Pages step in the Wercker Steps repository. Additionally, we need to ensure the box Wercker uses for our deployments has git and ssh installed. We can do this using the `install-packages` command. Here is our *final* `wercker.yml` file:
|
||||
|
||||
{{% code file="wercker.yml" %}}
|
||||
```yaml
|
||||
{{< code file="wercker.yml" >}}
|
||||
box: debian
|
||||
build:
|
||||
steps:
|
||||
@@ -276,8 +257,7 @@ deploy:
|
||||
token: $GIT_TOKEN
|
||||
domain: hugo-wercker.ig.nore.me
|
||||
basedir: public
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
### How does the GitHub Pages Configuration Work?
|
||||
|
||||
|
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Hosting on Bitbucket
|
||||
linktitle: Hosting on Bitbucket
|
||||
title: Host on Bitbucket
|
||||
linktitle: Host on Bitbucket
|
||||
description: You can use Bitbucket in conjunction with Aerobatic to build, deploy, and host a Hugo website.
|
||||
date: 2017-02-04
|
||||
publishdate: 2017-02-04
|
||||
@@ -30,14 +30,14 @@ You can use [Bitbucket](https://bitbucket.org/) and [Aerobatic](https://www.aero
|
||||
|
||||
If you haven't previously used Aerobatic, you'll first need to install the Command Line Interface (CLI) and create an account. For a list of all commands available, see the [Aerobatic CLI](https://www.aerobatic.com/docs/cli/) docs.
|
||||
|
||||
```bash
|
||||
```
|
||||
npm install aerobatic-cli -g
|
||||
aero register
|
||||
```
|
||||
|
||||
## Create and Deploy Site
|
||||
|
||||
```bash
|
||||
```
|
||||
hugo new site my-new-hugo-site
|
||||
cd my-new-hugo-site
|
||||
cd themes; git clone https://github.com/eliasson/liquorice
|
||||
@@ -61,7 +61,7 @@ We will now create a git repository and then push our code to Bitbucket. In Bitb
|
||||
[1]: /images/hosting-and-deployment/hosting-on-bitbucket/bitbucket-create-repo.png
|
||||
|
||||
|
||||
```bash
|
||||
```
|
||||
# initialize new git repository
|
||||
git init
|
||||
|
||||
@@ -88,7 +88,7 @@ In your Hugo website's Bitbucket repo;
|
||||
3. On the next screen, leave the default template and click Next.
|
||||
4. In the editor, paste in the yaml contents below and click Commit.
|
||||
|
||||
```bash
|
||||
```
|
||||
image: beevelop/nodejs-python
|
||||
pipelines:
|
||||
branches:
|
||||
@@ -109,7 +109,7 @@ pipelines:
|
||||
|
||||
This step only needs to be done once per account. From the command line;
|
||||
|
||||
```bash
|
||||
```
|
||||
aero apikey
|
||||
```
|
||||
|
||||
@@ -119,7 +119,7 @@ aero apikey
|
||||
|
||||
### Step 3: Edit and Commit Code
|
||||
|
||||
```bash
|
||||
```
|
||||
hugo new post/good-to-great.md
|
||||
hugo server --buildDrafts -t liquorice #Check that all looks good
|
||||
|
||||
|
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Hosting on Firebase
|
||||
linktitle: Hosting on Firebase
|
||||
title: Host on Firebase
|
||||
linktitle: Host on Firebase
|
||||
description: You can use Firebase's free tier to host your static website; this also gives you access to Firebase's NOSQL API.
|
||||
date: 2017-03-12
|
||||
publishdate: 2017-03-12
|
||||
@@ -29,19 +29,19 @@ aliases: []
|
||||
Go to the [Firebase console][console] and create a new project (unless you already have a project). You will need to globally install `firebase-tools` (node.js):
|
||||
|
||||
|
||||
```sh
|
||||
```
|
||||
npm install -g firebase-tools
|
||||
```
|
||||
|
||||
Log in to Firebase (setup on your local machine) using `firebase login`, which opens a browser where you can select your account. Use `firebase logout` in case you are already logged in but to the wrong account.
|
||||
|
||||
|
||||
```sh
|
||||
```
|
||||
firebase login
|
||||
```
|
||||
In the root of your Hugo project, initialize the Firebase project with the `firebase init` command:
|
||||
|
||||
```sh
|
||||
```
|
||||
firebase init
|
||||
```
|
||||
From here:
|
||||
@@ -56,7 +56,7 @@ From here:
|
||||
|
||||
To deploy your Hugo site, execute the `firebase deploy` command, and your site will be up in no time:
|
||||
|
||||
```sh
|
||||
```
|
||||
hugo && firebase deploy
|
||||
```
|
||||
|
||||
@@ -65,7 +65,7 @@ hugo && firebase deploy
|
||||
You can generate a deploy token using
|
||||
|
||||
|
||||
```sh
|
||||
```
|
||||
firebase login:ci
|
||||
```
|
||||
|
||||
@@ -77,7 +77,7 @@ This is a private secret and it should not appear in a public repository. Make s
|
||||
|
||||
You can then add a step in your build to do the deployment using the token:
|
||||
|
||||
```sh
|
||||
```
|
||||
firebase deploy --token $FIREBASE_DEPLOY_TOKEN
|
||||
```
|
||||
|
||||
|
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Hosting on GitHub
|
||||
linktitle: Hosting on GitHub
|
||||
title: Host on GitHub
|
||||
linktitle: Host on GitHub
|
||||
description: Deploy Hugo as a GitHub Pages project or personal/organizational site and automate the whole process with a simple shell script.
|
||||
date: 2014-03-21
|
||||
publishdate: 2014-03-21
|
||||
@@ -37,11 +37,11 @@ Make sure your `baseURL` key-value in your [site configuration](/getting-started
|
||||
|
||||
[As described in the GitHub Pages documentation][ghpfromdocs], you can deploy from a folder called `docs/` on your master branch. To effectively use this feature with Hugo, you need to change the Hugo publish directory in your [site's][config] `config.toml` and `config.yaml`, respectively:
|
||||
|
||||
```yaml
|
||||
```
|
||||
publishDir: docs
|
||||
```
|
||||
|
||||
```toml
|
||||
```
|
||||
publishDir = "docs"
|
||||
```
|
||||
|
||||
@@ -69,7 +69,7 @@ These steps only need to be done once. Replace `upstream` with the name of your
|
||||
|
||||
First, add the `public` folder to your `.gitignore` file at the project root so that the directory is ignored on the master branch:
|
||||
|
||||
```bash
|
||||
```
|
||||
echo "public" >> .gitignore
|
||||
```
|
||||
|
||||
@@ -77,7 +77,7 @@ echo "public" >> .gitignore
|
||||
|
||||
You can now initialize your `gh-pages` branch as an empty [orphan branch][]:
|
||||
|
||||
```bash
|
||||
```
|
||||
git checkout --orphan gh-pages
|
||||
git reset --hard
|
||||
git commit --allow-empty -m "Initializing gh-pages branch"
|
||||
@@ -89,23 +89,21 @@ git checkout master
|
||||
|
||||
Now check out the `gh-pages` branch into your `public` folder using git's [worktree feature][]. Essentially, the worktree allows you to have multiple branches of the same local repository to be checked out in different directories:
|
||||
|
||||
```sh
|
||||
```
|
||||
rm -rf public
|
||||
git worktree add -B gh-pages public upstream/gh-pages
|
||||
```
|
||||
|
||||
Regenerate the site using the `hugo` command and commit the generated files on the `gh-pages` branch:
|
||||
|
||||
{{% code file="commit-gh-pages-files.sh"%}}
|
||||
```bash
|
||||
{{< code file="commit-gh-pages-files.sh">}}
|
||||
hugo
|
||||
cd public && git add --all && git commit -m "Publishing to gh-pages" && cd ..
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
If the changes in your local `gh-pages` branch look alright, push them to the remote repo:
|
||||
|
||||
```bash
|
||||
```
|
||||
git push upstream gh-pages
|
||||
```
|
||||
|
||||
@@ -122,8 +120,7 @@ After a short while, you'll see the updated contents on your GitHub Pages site.
|
||||
|
||||
To automate these steps, you can create a script with the following contents:
|
||||
|
||||
{{% code file="publish_to_ghpages.sh" %}}
|
||||
```sh
|
||||
{{< code file="publish_to_ghpages.sh" >}}
|
||||
#!/bin/sh
|
||||
|
||||
DIR=$(dirname "$0")
|
||||
@@ -153,8 +150,7 @@ hugo
|
||||
|
||||
echo "Updating gh-pages branch"
|
||||
cd public && git add --all && git commit -m "Publishing to gh-pages (publish.sh)"
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
This will abort if there are pending changes in the working directory and also makes sure that all previously existing output files are removed. Adjust the script to taste, e.g. to include the final push to the remote repository if you don't need to take a look at the gh-pages branch before pushing. Or adding `echo yourdomainname.com >> CNAME` if you set up for your gh-pages to use customize domain.
|
||||
|
||||
@@ -193,7 +189,7 @@ You're almost done. You can also add a `deploy.sh` script to automate the preced
|
||||
|
||||
The following are the contents of the `deploy.sh` script:
|
||||
|
||||
```sh
|
||||
```
|
||||
#!/bin/bash
|
||||
|
||||
echo -e "\033[0;32mDeploying updates to GitHub...\033[0m"
|
||||
|
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Hosting on GitLab
|
||||
linktitle: Hosting on GitLab
|
||||
title: Host on GitLab
|
||||
linktitle: Host on GitLab
|
||||
description: GitLab makes it incredibly easy to build, deploy, and host your Hugo website via their free GitLab Pages service, which provides native support for Hugo.
|
||||
date: 2016-06-23
|
||||
publishdate: 2016-06-23
|
||||
@@ -31,14 +31,13 @@ aliases: [/tutorials/hosting-on-gitlab/]
|
||||
|
||||
## Create .gitlab-ci.yml
|
||||
|
||||
```bash
|
||||
```
|
||||
cd your-hugo-site
|
||||
```
|
||||
|
||||
In the root directory of your Hugo site, create a `.gitlab-ci.yml` file. The `.gitlab-ci.yml` configures the GitLab CI on how to build your page. Simply add the content below.
|
||||
|
||||
{{% code file="gitlab-ci.yml" %}}
|
||||
```yml
|
||||
{{< code file="gitlab-ci.yml" >}}
|
||||
image: publysher/hugo
|
||||
|
||||
pages:
|
||||
@@ -49,14 +48,13 @@ pages:
|
||||
- public
|
||||
only:
|
||||
- master
|
||||
```
|
||||
{{% /code %}}
|
||||
{{< /code >}}
|
||||
|
||||
## Push Your Hugo Website to GitLab
|
||||
|
||||
Next, create a new repository on GitLab. It is *not* necessary to make the repository public. In addition, you might want to add `/public` to your .gitignore file, as there is no need to push compiled assets to GitLab or keep your output website in version control.
|
||||
|
||||
```bash
|
||||
```
|
||||
# initialize new git repository
|
||||
git init
|
||||
|
||||
|
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Hosting on Netlify
|
||||
linktitle: Hosting on Netlify
|
||||
title: Host on Netlify
|
||||
linktitle: Host on Netlify
|
||||
description: Netlify can host your Hugo site with CDN, continuous deployment, 1-click HTTPS, an admin GUI, and its own CLI.
|
||||
date: 2017-02-01
|
||||
publishdate: 2017-02-01
|
||||
@@ -65,7 +65,7 @@ Setting the build command to `hugo` will build your site according to the curren
|
||||
|
||||
If you want to tell Netlify to build with a specific version, you can append an underscore followed by the version number to the build command:
|
||||
|
||||
```bash
|
||||
```
|
||||
hugo_0.19
|
||||
```
|
||||
|
||||
@@ -93,7 +93,7 @@ The [`git clone` method for installing themes][installthemes] is not supported b
|
||||
|
||||
A *better* approach is to install a theme as a proper git submodule. You can [read the GitHub documentation for submodules][ghsm] or those found on [Git's website][gitsm] for more information, but the command is similar to that of `git clone`:
|
||||
|
||||
```bash
|
||||
```
|
||||
cd themes
|
||||
git submodule add https://github.com/<THEMECREATOR>/<THEMENAME>
|
||||
```
|
||||
|
Reference in New Issue
Block a user