When building the extended version of Hugo using the Dockerfile and
`--build-arg HUGO_BUILD_TAGS=extended`, the obtained Docker container is
broken, because the source is build under alpine 3.11 and the compiled
binary is copied to an image based on alpine 3.10. This problem was most
likely introduced due to an update of the golang base image.
This commit changes the base image from alpine:3.10 to alpine:3.11,
fixing extended version builds.
- Use Alpine for both stages for consistency.
- Switch to mage from go install as dictated in the latest docs.
- Easy switch to building Hugo Extended by directly setting HUGO_BUILD_TAGS flag at image build time: `docker build --build-arg HUGO_BUILD_TAGS=extended .`
- Update to Go 1.13 and Alpine 3.10.
- The only possibly breaking change: Moved the `hugo` binary in the final stage from /hugo to /usr/bin/hugo so one can simply run `hugo` without having to search around for its location.
Switching the base image for the final build to alpine as it still
provides a minimal interface, but has a mechanism for easily including
relevant CA certificates. This is currently pinned to a tagged version,
though since none of the underlying mechanisms are used this should
balance both remaining stable, supported for a period of time, and
providing usable functionality.
Resolves#5970
Affects #5056
Before this commit, you would have to use page bundles to do image processing etc. in Hugo.
This commit adds
* A new `/assets` top-level project or theme dir (configurable via `assetDir`)
* A new template func, `resources.Get` which can be used to "get a resource" that can be further processed.
This means that you can now do this in your templates (or shortcodes):
```bash
{{ $sunset := (resources.Get "images/sunset.jpg").Fill "300x200" }}
```
This also adds a new `extended` build tag that enables powerful SCSS/SASS support with source maps. To compile this from source, you will also need a C compiler installed:
```
HUGO_BUILD_TAGS=extended mage install
```
Note that you can use output of the SCSS processing later in a non-SCSSS-enabled Hugo.
The `SCSS` processor is a _Resource transformation step_ and it can be chained with the many others in a pipeline:
```bash
{{ $css := resources.Get "styles.scss" | resources.ToCSS | resources.PostCSS | resources.Minify | resources.Fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
The transformation funcs above have aliases, so it can be shortened to:
```bash
{{ $css := resources.Get "styles.scss" | toCSS | postCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Digest }}" media="screen">
```
A quick tip would be to avoid the fingerprinting part, and possibly also the not-superfast `postCSS` when you're doing development, as it allows Hugo to be smarter about the rebuilding.
Documentation will follow, but have a look at the demo repo in https://github.com/bep/hugo-sass-test
New functions to create `Resource` objects:
* `resources.Get` (see above)
* `resources.FromString`: Create a Resource from a string.
New `Resource` transformation funcs:
* `resources.ToCSS`: Compile `SCSS` or `SASS` into `CSS`.
* `resources.PostCSS`: Process your CSS with PostCSS. Config file support (project or theme or passed as an option).
* `resources.Minify`: Currently supports `css`, `js`, `json`, `html`, `svg`, `xml`.
* `resources.Fingerprint`: Creates a fingerprinted version of the given Resource with Subresource Integrity..
* `resources.Concat`: Concatenates a list of Resource objects. Think of this as a poor man's bundler.
* `resources.ExecuteAsTemplate`: Parses and executes the given Resource and data context (e.g. .Site) as a Go template.
Fixes#4381Fixes#4903Fixes#4858
- Hugo container is based on SCRATCH to further reduce the footprint
and the vulnerability surface
- Update Alpine image to 3.7 in the build container
- Update Go Lang to 1.10 in the build container
- Add .dockerignore file per the Docker best practices
Closes#4154, #4155, #4157
The present Dockerfile in master does not build a Hugo container. The
build container prematurely exits because `dep ensure` can not locate
`Gopkg.toml` due to the source files not being copied/added to the
container prior to running this command. The minimal change require
to resolve the issue is merely move the ADD source before the RUN dep.
Fixes#4076Resolves#4077
To maximize the usage of cache, split the govendor get in steps:
- govendor fetch to get the pinned versions of dependencies
- go install to actually build the binary
Doing so allows not to re-download the whole dependencies when changing
lines in hugo repository
The current Dockerfile generates an image of 16.6MB
Signed-off-by: Thibault Jamet <tjamet@users.noreply.github.com>
Docker has recently introduces buikld-stages (as of version 17.05)
Build stages allows to benefit the docker build cache as well as
reducing the size of the resulting image c.f.
https://docs.docker.com/engine/userguide/eng-image/multistage-build/
This change allows to have faster builds when running `docker build`
several times after changing some little code
Signed-off-by: Thibault Jamet <tjamet@users.noreply.github.com>
It's pointless to set `/bin/sh` as entrypoint. `/bin/sh` is already the default command, and on the top of that, setting `/bin/sh` as entrypoint ignores the command.
Hugo has been confirmed which runs on Golang 1.6, as travis uses 1.6
vesion. Dockerfile must be consistend with it so it has to use golang:1.6
as base image than golang:1.5
