The world’s fastest framework for building websites.
Go to file
Owen Waller 6b28e38cea Expansion of unit tests for utils/utils.go
This commit expands the test coverage for the utils/utils.go module.

The utils module uses the 'github.com/spf13/jwalterweatherman' (aka jww)
package for logging. The tests take the approach of examining the log
file that is produced by this module to verify correct behaviour. This
avoids refactoring the utils module.

The log file messages written by the jww module are of the form:
<log level>: yyyy/mm/dd <string|error message>

The checkLogFile function checks each of these parts in turn except for
the date string, which is currently ignored. The final part of the log
file format can either be a single error message, or a series of
strings followed by an error message. Both the error message and the
series of strings can be empty strings.

The log file is checked using a combination of the regex package,
along with the bufio scanner type. Each test logs to its own temporary
log file. This is achieved with standard test setup and teardown
functions.

One consequence of these tests is that StopOnErr has been refactored
into call a new unexported function doStopOnErr which contains the bulk
of the original logic. This allows the same testing approach to be used
with StopOnErr as with CheckErr and cutUsageMessage, rather than look at
the exit status code of the test itself.

An unfortunate side effect of this is that the author of the tests must
now know if a log file is expected or not. If doStopOnErr determines
that an empty error message would be written to the log file then
nothing is written. In the context of the tests this means that the log
file created by the test would have no contents. Consequently there
would be nothing for the test to examine. This situation is indicated by
the boolean flag logFileExoected in the testData struct, and processed
by the logFileIsExpectedAndValid function.

Although not ideal this was deemed a reasonable compromise.
2015-02-17 02:20:00 -07:00
bufferpool Adding BufferPool. Implementing BP in ReaderTo{Bytes,String}(). 2015-01-30 11:12:07 -08:00
commands Make "Indexes" the alias and "Taxonomies" the canonical name 2015-02-16 13:16:17 -07:00
create parser.FormatSanitize() MetaDataFormat for date too 2015-02-08 09:55:20 -07:00
docs [Docs] Minor copyediting of highlighting.md 2015-02-17 01:59:40 -07:00
examples [Docs] Complete the transition from "indexes" to "taxonomies" (almost) 2015-01-29 12:48:14 -07:00
helpers Add data files support in themes 2015-02-11 20:24:56 +01:00
hugofs Setting to filesystems to the afero.fs interface so can be easily swapped out. 2014-11-04 00:30:35 -05:00
hugolib Fix broken data dir test 2015-02-11 21:55:11 +01:00
livereload url_path => urlPath 2015-01-30 16:21:46 +01:00
parser Upgrade from gopkg.in/yaml.v1 to gopkg.in/yaml.v2 2015-01-24 04:30:00 -07:00
source ERROR-log on symbolic links 2014-12-10 20:32:39 +01:00
target Fix various Windows-issues 2014-12-09 09:43:15 -05:00
tpl Use .Site.Params.description as fallback for social partials 2015-02-01 19:56:21 +01:00
transform Improve abs url replacement speed 2015-02-16 08:24:42 -05:00
utils Expansion of unit tests for utils/utils.go 2015-02-17 02:20:00 -07:00
watcher use fsnotify 0.9.3 2015-01-05 18:31:51 +01:00
.gitignore Improve abs url replacement speed 2015-02-16 08:24:42 -05:00
.mailmap Add .mailmap to get a more correct author log 2015-01-28 16:50:36 +01:00
.travis.yml Bumping Travis to test go 1.3 & 1.4 2014-12-30 14:58:48 -05:00
baseline.txt Adding baseline 2013-11-05 22:51:40 +00:00
LICENSE.md adding hugo 2013-07-04 11:32:55 -04:00
main.go More proofreading and minor revisions to Hugo docs 2014-09-08 11:41:10 -04:00
Makefile Added top level .Hugo variable with version, commit and generator information + docs 2015-01-19 01:22:23 +01:00
README.md README.me: Add linefeed that got lost in the last commit 2015-02-16 09:07:52 -07:00
wercker.yml Create wercker.yml 2014-01-15 11:02:24 -05:00

Hugo

A Fast and Flexible Static Site Generator built with love by spf13 and friends in Go.

Build Status wercker status Build status

Overview

Hugo is a static site generator written in Go. It is optimized for speed, easy use and configurability. Hugo takes a directory with content and templates and renders them into a full HTML website.

Hugo relies on Markdown files with front matter for meta data. And you can run Hugo from any directory. This works well for shared hosts and other systems where you don't have a privileged account.

Hugo renders a typical website of moderate size in a fraction of a second. A good rule of thumb is that each piece of content renders in around 1 millisecond.

Hugo is meant to work well for any kind of website including blogs, tumbles and docs.

Supported Architectures

Currently Hugo exists for Windows, Linux, FreeBSD and OS X for x64 and i386 architectures.

Complete documentation is available at Hugo Documentation.

Choose How to Install

If you want to use Hugo as your site generator, simply install the Hugo binaries. The Hugo binaries have no external dependencies.

To contribute to the Hugo source code or documentation, you should fork the Hugo GitHub project and clone it to your local machine.

Finally, you can install the Hugo source code with go, build the binaries yourself, and run Hugo that way. Building the binaries is an easy task for an experienced go getter.

Install Hugo as Your Site Generator (Binary Install)

Use the installation instructions in the Hugo documentation.

Clone the Hugo Project (Contributor)

  1. Make sure your local environment has the following software installed:

    • Git
    • Go 1.3+ (Go 1.4+ on Windows, see Go Issue #8090)
    • Mercurial
    • Bazaar
  2. Fork the Hugo project on Github.

  3. Clone your fork.

    git clone https://github.com/YOURNAME/hugo

  4. Change into the hugo directory.

    cd hugo

  5. Install the Hugo projects package dependencies.

    go get

  6. Use a symbolic link to add Hugo to your $GOPATH.

    ln -s /path/to/your/hugo $GOPATH/src/github.com/spf13/hugo

    Go expects all of your libraries to be found in$GOPATH.

Build and Install the Binaries from Source (Advanced Install)

Add Hugo and its package dependencies to your go src directory.

go get -v github.com/spf13/hugo

Once the get completes, you should find your new hugo (or hugo.exe) executable sitting inside $GOPATH/bin/.

To update Hugos dependencies, use go get with the -u option.

go get -u -v github.com/spf13/hugo

Contributing Code

Contributors should build Hugo and test their changes before submitting a code change.

Building Hugo with Your Changes

cd /path/to/hugo
go build -o hugo main.go
mv hugo /usr/local/bin/

Adding compile information to Hugo

When Hugo is built using the above steps, the version sub-command will include the mdate of the Hugo executable, similar to the following:

Hugo Static Site Generator v0.13-DEV buildDate: 2014-12-24T04:46:03-07:00

Instead, it is possible to have the version sub-command return information about the git commit used and time of compilation using build flags.

To do this, replace the go build command with the following (replace /path/to/hugo with the actual path):

go build -ldflags "-X /path/to/hugo/hugolib.CommitHash `git rev-parse --short HEAD 2>/dev/null` -X github.com/spf13/hugo/hugolib.BuildDate `date +%FT%T%z`"

This will result in hugo version output that looks similar to:

Hugo Static Site Generator v0.13-DEV-8042E77 buildDate: 2014-12-25T03:25:57-07:00

The format of the date is configurable via the Params.DateFormat setting. DateFormat is a string value representing the Go time layout that should be used to format the date output. If Params.DateFormat is not set, time.RFC3339 will be used as the default format. See Go's "time" package documentation for more information.

Configuration setting using config.yaml as example:

Params:
   DateFormat: "2006-01-02"

Will result in:

Hugo Static Site Generator v0.13-DEV buildDate: 2014-10-16
Hugo Static Site Generator v0.13-DEV-24BBFE7 buildDate: 2014-10-16

Running Hugo

cd /path/to/hugo
go install github.com/spf13/hugo/hugolib
go run main.go

Contribution Guidelines

We welcome your contributions. To make the process as seamless as possible, we ask for the following:

  • Go ahead and fork the project and make your changes. We encourage pull requests to discuss code changes.
  • When you're ready to create a pull request, be sure to:
    • Have test cases for the new code. If you have questions about how to do it, please ask in your pull request.
    • Run go fmt
    • Squash your commits into a single commit. git rebase -i. It's okay to force update your pull request.
    • Make sure go test ./... passes, and go build completes. Our Travis CI loop will catch most things that are missing. The exception: Windows. We run on Windows from time to time, but if you have access, please check on a Windows machine too.

Complete documentation is available at Hugo Documentation.

Analytics Bitdeli Badge