Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up

Build, archive and release.

License

NotificationsYou must be signed in to change notification settings

gohugoio/hugoreleaser

Repository files navigation

Tests on Linux, MacOS and WindowsGo Report CardcodecovGoDoc

Configuration

Configuration File

Hugoreleaser reads its main configuration from a file namedhugoreleaser.yaml in the working directory. Seethis project's configuration for an annotated example.

Definitions

Hugoreleaser supports YAML anchors and aliases, and has a reserved section fordefinitions. This is useful for defining common settings that can be reused in multiple places, e.g.

definitions:archive_type_zip:&archive_type_ziptype:format:zipextension:.zip          -goarch:amd64archives:  -paths:      -builds/**/windows/**archive_settings:*archive_type_zip

Archive Aliases

See Hugo's usehere.

Template Expansion

Hugoreleaser supports Go template syntax in all fields with suffix_template (e.g.name_template used to create archive names).

The data received in the template (e.g. the ".") is:

FieldDescription
ProjectThe project name as defined in config.
TagThe tag as defined by the -tag flag.
GoosThe current GOOS.
GoarchThe current GOARCH.

In addition to Go'sbuilt-ins, we have added a small number of convenient template funcs:

  • upper
  • lower
  • replace (usesstrings.ReplaceAll)
  • trimPrefix
  • trimSuffix

With that, a name template may look like this:

name_template ="{{ .Project }}_{{ .Tag | trimPrefix `v` }}_{{ .Goos }}-{{ .Goarch }}"

Environment Variables

The order of presedence for environment variables/flags:

  1. Flags (e.g.-tag)
  2. OS environment variables.
  3. Environment variables defined inhugoreleaser.env.

Ahugoreleaser.env file will, if found in the current directory, be parsed and loaded into the environment of the running process. The format is simple, a text files of key-value-pairs on the formKEY=value, empty lines and lines starting with# is ignored:

Environment variable expressions inhugoreleaser.yaml on the form${VAR} will be expanded before it's parsed.

An examplehugoreleaser.env with the enviromnent for the next release may look like this:

HUGORELEASER_TAG=v1.2.3HUGORELEASER_COMMITISH=mainMYPROJECT_RELEASE_NAME=First Release!MYPROJECT_RELEASE_DRAFT=false

In the above, the variables prefixedHUGORELEASER_ will be used to set the flags when running thehugoreleaser commands.

The other custom variables can be used inhugoreleaser.yaml, e.g:

release_settings:name: ${MYPROJECT_RELEASE_NAME}

Note the special@U (Unquoute) syntax. The fielddraft is a boolean and cannot be quouted, but this would create ugly validation errors in TOML aware editors. The construct above signals that the quoutes (single or double) should be removed before doing any variable expansion.

Glob Matching

Hugo releaser supports the Glob rules as defined inGobwas Glob with one additional rule: Glob patterns can be negated with a! prefix.

The CLI-paths flag is a slice an, if repeated for a given prefix, will be ANDed together, e.g.:

hugoreleaser build  -paths "builds/**" -paths "!builds/**/arm64"

The above will build everything, expect the ARM64GOARCH.

Partitions

Manual Partitioning

The configuration file and the (mimics the directory structure inside/dist) creates a simple tree structure that can be used to partition a build/release. All commands takes one or more-paths flag values. This is aGlob Path matching builds to cover or releases to release (the latter is only relevant for the last step). Hugo has partitioned its builds using a container name as the first path element. With that, releasing may look something like this:

# Run this in container1hugoreleaser build --paths "builds/container1/**"# Run this in container2, using the same /dist as the first step.hugoreleaser build --paths "builds/container2/**"hugoreleaser archivehugoreleaser release

Parallelism

The build command takes the optional-chunks and-chunk-index which could be used to automatically split the builds to speed up pipelines., e.g. usingCircle CI's Job Splitting.

SeeHugo v0.102.0 Release Notes for more information.

Plugins

Hugoreleaser supportsGo Module plugins to create archives. See theDeb Plugin for an example.

See theHugoreleaser Plugins API for API and more information.

Release Notes

The config maprelease_notes_settings has 3 options for how to handle release notes:

  1. Set afilename
  2. Setgenerate_on_host=true and let GitHub do it.
  3. Setgenerate=true and let Hugoreleaser do it.

There are more details about change grouping etc. in thisthis project's configuration.

For the third option, you can set a custom release notes template to use intemplate_filename. See the default template instaticfiles/templates/release-notes.gotmpl for an example.

Why another Go release tool?

This project was created becauseHugo had some issues that seemed unsolvable with Goreleaser:

  • We had a CI release that timed out a lot (1 hour). And since Goreleaser creates the tag as the first step, we often ended up having to delete the tag and start over, creating all sorts of issues.
  • We wanted to add more build variants, but we couldn't.

Hugo has used this tool for all of its releases sincev0.102.0, and the release time has gone down from 50-60 minutes to around 10 minutes.


[8]ページ先頭

©2009-2025 Movatter.jp