2017-10-31 17:38:29 +00:00
SHELL = bash
2017-08-18 05:29:26 +00:00
PROJECT_ROOT := $( patsubst %/,%,$( dir $( abspath $( lastword $( MAKEFILE_LIST) ) ) ) )
2020-05-15 16:19:59 +00:00
THIS_OS := $( shell uname | cut -d- -f1)
2020-12-14 13:27:19 +00:00
THIS_ARCH := $( shell uname -m)
2017-08-18 05:29:26 +00:00
GIT_COMMIT := $( shell git rev-parse HEAD)
GIT_DIRTY := $( if $( shell git status --porcelain) ,+CHANGES)
2017-11-03 23:01:01 +00:00
GO_LDFLAGS := " -X github.com/hashicorp/nomad/version.GitCommit= $( GIT_COMMIT) $( GIT_DIRTY) "
2021-04-01 20:27:18 +00:00
2022-01-18 18:17:37 +00:00
i f n e q ( M S Y S _ N T , $( THIS_OS ) )
# GOPATH supports PATH style multi-paths; assume the first entry is favorable.
# Necessary because new Circle images override GOPATH with multiple values.
# See: https://discuss.circleci.com/t/gopath-is-set-to-multiple-directories/7174
GOPATH = $( shell go env GOPATH | cut -d: -f1)
e n d i f
2021-04-01 20:27:18 +00:00
GO_TAGS ?=
i f e q ( $( CI ) , t r u e )
GO_TAGS := codegen_generated $( GO_TAGS)
e n d i f
2017-08-18 05:29:26 +00:00
2021-08-09 20:53:44 +00:00
# Don't embed the Nomad UI when the NOMAD_NO_UI env var is set.
i f n d e f N O M A D _ N O _ U I
GO_TAGS := ui $( GO_TAGS)
e n d i f
2020-05-15 16:19:59 +00:00
GO_TEST_CMD = $( if $( shell command -v gotestsum 2>/dev/null) ,gotestsum --,go test )
2018-12-15 19:00:27 +00:00
2019-01-23 20:39:34 +00:00
i f e q ( $( origin GOTEST_PKGS_EXCLUDE ) , u n d e f i n e d )
GOTEST_PKGS ?= "./..."
e l s e
2019-09-03 15:04:27 +00:00
GOTEST_PKGS = $( shell go list ./... | sed 's/github.com\/hashicorp\/nomad/./' | egrep -v " ^( $( GOTEST_PKGS_EXCLUDE) )(/.*)? $$ " )
2019-01-23 20:39:34 +00:00
e n d i f
2020-11-20 14:26:02 +00:00
# tag corresponding to latest release we maintain backward compatibility with
2021-02-01 01:23:22 +00:00
PROTO_COMPARE_TAG ?= v1.0.3$( if $( findstring ent,$( GO_TAGS) ) ,+ent,)
2020-11-20 14:26:02 +00:00
Adopt go-changelog in Nomad (#10825)
Adopts [`go-changelog`](https://github.com/hashicorp/go-changelog) for managing Nomad's changelog. `go-changelog` is becoming the HashiCorp defacto standard tool for managing changelog, e.g. [Consul](https://github.com/hashicorp/consul/pull/8387), [Vault](https://github.com/hashicorp/vault/pull/10363), [Waypoint](https://github.com/hashicorp/waypoint/pull/1179). [Consul](https://github.com/hashicorp/consul/pull/8387) seems to be the first product to adopt it, and its PR has the most context - though I've updated `.changelog/README.md` with the relevant info here.
## Changes to developers workflow
When opening PRs, developers should add a changelog entry in `.changelog/<PR#>.txt`. Check [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#developer-guide).
For the WIP release, entries can be amended even after the PR merged, and new files may be added post-hoc (e.g. during transition period, missed accidentally, community PRs, etc).
### Transitioning
Pending PRs can start including the changelog entry files immediately.
For 1.1.3/1.0.9 cycle, the release coordinator should create the entries for any PR that gets merged without a changelog entry file. They should also move any 1.1.3 entry in CHANGELOG.md to a changelog entry file, as this PR done for GH-10818.
## Changes to release process
Before cutting a release, release coordinator should update the changelog by inserting the output of `make changelog` to CHANGELOG.md with appropriate headers. See [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#how-to-generate-changelog-entries-for-release) for more details.
## Details
go-changelog is a basic templating engine for maintaining changelog in HashiCorp environment.
It expects the changelog entries as files indexed by their PR number. The CLI generates the changelog section for a release by comparing two git references (e.g. `HEAD` and the latest release, e.g. `v1.1.2`), and still requires manual process for updating CHANGELOG.md and final formatting.
The approach has many nice advantages:
* Avoids changelog related merge conflicts: Each PR touches different file!
* Copes with amendments and post-PR updates: Just add or update a changelog entry file using the original PR numbers.
* Addresses the release backporting scenario: Cherry-picking PRs will cherry-pick the relevant changelog entry automatically!
* Only relies on data available through `git` - no reliance on GitHub metadata or require GitHub credentials
The approach has few downsides though:
* CHANGELOG.md going stale during development and must be updated manually before cutting the release
* Repository watchers can no longer glance at the CHANGELOG.md to see upcoming changes
* We can periodically update the file, but `go-changelog` tool does not aid with that
* `go-changelog` tool does not offer good error reporting. If an entry is has an invalid tag (e.g. uses `release-note:bugfix` instead of `release-note:bug`), the entry will be dropped silently
* We should update go-changelog to warn against unexpected entry tags
* TODO: Meanwhile, PR reviewers and release coordinators should watch out
## Potential follow ups
We should follow up with CI checks to ensure PR changes include a warning. I've opted not to include that now. We still make many non-changelog-worth PRs for website/docs, for large features that get merged in multiple small PRs. I did not want to include a check that fails often.
Also, we should follow up to have `go-changelog` emit better warnings on unexpected tag.
2021-07-06 14:46:53 +00:00
# LAST_RELEASE is the git sha of the latest release corresponding to this branch. main should have the latest
# published release, but backport branches should point to the parent tag (e.g. 1.0.8 in release-1.0.9 after 1.1.0 is cut).
2022-02-01 16:13:22 +00:00
LAST_RELEASE ?= v1.2.5
Adopt go-changelog in Nomad (#10825)
Adopts [`go-changelog`](https://github.com/hashicorp/go-changelog) for managing Nomad's changelog. `go-changelog` is becoming the HashiCorp defacto standard tool for managing changelog, e.g. [Consul](https://github.com/hashicorp/consul/pull/8387), [Vault](https://github.com/hashicorp/vault/pull/10363), [Waypoint](https://github.com/hashicorp/waypoint/pull/1179). [Consul](https://github.com/hashicorp/consul/pull/8387) seems to be the first product to adopt it, and its PR has the most context - though I've updated `.changelog/README.md` with the relevant info here.
## Changes to developers workflow
When opening PRs, developers should add a changelog entry in `.changelog/<PR#>.txt`. Check [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#developer-guide).
For the WIP release, entries can be amended even after the PR merged, and new files may be added post-hoc (e.g. during transition period, missed accidentally, community PRs, etc).
### Transitioning
Pending PRs can start including the changelog entry files immediately.
For 1.1.3/1.0.9 cycle, the release coordinator should create the entries for any PR that gets merged without a changelog entry file. They should also move any 1.1.3 entry in CHANGELOG.md to a changelog entry file, as this PR done for GH-10818.
## Changes to release process
Before cutting a release, release coordinator should update the changelog by inserting the output of `make changelog` to CHANGELOG.md with appropriate headers. See [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#how-to-generate-changelog-entries-for-release) for more details.
## Details
go-changelog is a basic templating engine for maintaining changelog in HashiCorp environment.
It expects the changelog entries as files indexed by their PR number. The CLI generates the changelog section for a release by comparing two git references (e.g. `HEAD` and the latest release, e.g. `v1.1.2`), and still requires manual process for updating CHANGELOG.md and final formatting.
The approach has many nice advantages:
* Avoids changelog related merge conflicts: Each PR touches different file!
* Copes with amendments and post-PR updates: Just add or update a changelog entry file using the original PR numbers.
* Addresses the release backporting scenario: Cherry-picking PRs will cherry-pick the relevant changelog entry automatically!
* Only relies on data available through `git` - no reliance on GitHub metadata or require GitHub credentials
The approach has few downsides though:
* CHANGELOG.md going stale during development and must be updated manually before cutting the release
* Repository watchers can no longer glance at the CHANGELOG.md to see upcoming changes
* We can periodically update the file, but `go-changelog` tool does not aid with that
* `go-changelog` tool does not offer good error reporting. If an entry is has an invalid tag (e.g. uses `release-note:bugfix` instead of `release-note:bug`), the entry will be dropped silently
* We should update go-changelog to warn against unexpected entry tags
* TODO: Meanwhile, PR reviewers and release coordinators should watch out
## Potential follow ups
We should follow up with CI checks to ensure PR changes include a warning. I've opted not to include that now. We still make many non-changelog-worth PRs for website/docs, for large features that get merged in multiple small PRs. I did not want to include a check that fails often.
Also, we should follow up to have `go-changelog` emit better warnings on unexpected tag.
2021-07-06 14:46:53 +00:00
2017-08-18 05:29:26 +00:00
default : help
2019-05-10 14:14:18 +00:00
i f e q ( $( CI ) , t r u e )
$( info Running in a CI environment, verbose mode is disabled)
e l s e
VERBOSE = "true"
e n d i f
2017-12-06 19:30:31 +00:00
2020-12-18 17:54:14 +00:00
i f e q ( L i n u x , $( THIS_OS ) )
ALL_TARGETS = linux_386 \
2017-08-18 05:29:26 +00:00
linux_amd64 \
linux_arm \
linux_arm64 \
windows_386 \
windows_amd64
e n d i f
2020-12-14 13:27:19 +00:00
i f e q ( s 3 9 0 x , $( THIS_ARCH ) )
ALL_TARGETS = linux_s390x
e n d i f
2017-08-18 05:29:26 +00:00
i f e q ( D a r w i n , $( THIS_OS ) )
2021-01-12 20:52:30 +00:00
ALL_TARGETS = darwin_amd64
2017-08-18 05:29:26 +00:00
e n d i f
2017-09-06 22:46:31 +00:00
i f e q ( F r e e B S D , $( THIS_OS ) )
2020-12-18 17:54:14 +00:00
ALL_TARGETS = freebsd_amd64
2017-09-06 22:46:31 +00:00
e n d i f
2020-12-18 17:54:14 +00:00
SUPPORTED_OSES = Darwin Linux FreeBSD Windows MSYS_NT
2021-10-15 15:12:59 +00:00
CGO_ENABLED = 1
2019-08-13 14:12:57 +00:00
# include per-user customization after all variables are defined
- i n c l u d e G N U M a k e f i l e . l o c a l
2020-12-16 16:01:50 +00:00
pkg/%/nomad : GO_OUT ?= $@
2021-01-12 20:09:40 +00:00
pkg/%/nomad : CC ?= $( shell go env CC )
2020-12-16 16:01:50 +00:00
pkg/%/nomad : ## Build Nomad for GOOS_GOARCH, e.g. pkg/linux_amd64/nomad
2020-12-18 17:54:14 +00:00
i f e q ( , $( findstring $ ( THIS_OS ) ,$ ( SUPPORTED_OSES ) ) )
$( warning WARNING: Building Nomad is only supported on $( SUPPORTED_OSES) ; not $( THIS_OS) )
e n d i f
2017-09-19 14:47:10 +00:00
@echo " ==> Building $@ with tags $( GO_TAGS) ... "
2021-10-15 15:12:59 +00:00
@CGO_ENABLED= $( CGO_ENABLED) \
2020-12-16 16:01:50 +00:00
GOOS = $( firstword $( subst _, ,$* ) ) \
GOARCH = $( lastword $( subst _, ,$* ) ) \
2021-01-12 20:09:40 +00:00
CC = $( CC) \
2020-12-16 16:01:50 +00:00
go build -trimpath -ldflags $( GO_LDFLAGS) -tags " $( GO_TAGS) " -o $( GO_OUT)
2021-04-02 20:29:57 +00:00
i f n e q ( a r m v 7 l , $( THIS_ARCH ) )
pkg/linux_arm/nomad : CC = arm -linux -gnueabihf -gcc
e n d i f
i f n e q ( a a r c h 6 4 , $( THIS_ARCH ) )
pkg/linux_arm64/nomad : CC = aarch 64-linux -gnu -gcc
e n d i f
2021-10-15 15:12:59 +00:00
i f e q ( D a r w i n , $( THIS_OS ) )
pkg/linux_%/nomad : CGO_ENABLED = 0
e n d i f
2020-12-16 16:01:50 +00:00
pkg/windows_%/nomad : GO_OUT = $@.exe
2020-03-03 12:25:21 +00:00
2017-08-18 05:29:26 +00:00
# Define package targets for each of the build targets we actually have on this system
d e f i n e m a k e P a c k a g e T a r g e t
pkg/$(1).zip : pkg /$( 1) /nomad
@echo " ==> Packaging for $( 1) ... "
2017-08-29 05:29:49 +00:00
@zip -j pkg/$( 1) .zip pkg/$( 1) /*
2017-08-18 05:29:26 +00:00
e n d e f
# Reify the package targets
$( foreach t ,$ ( ALL_TARGETS ) ,$ ( eval $ ( call makePackageTarget ,$ ( t ) ) ) )
.PHONY : bootstrap
2019-04-17 22:28:17 +00:00
bootstrap : deps lint -deps git -hooks # Install all dependencies
2017-08-18 05:29:26 +00:00
.PHONY : deps
2017-10-24 17:49:53 +00:00
deps : ## Install build and development dependencies
2017-08-18 05:29:26 +00:00
@echo "==> Updating build dependencies..."
2021-03-09 18:49:48 +00:00
go install github.com/hashicorp/go-bindata/go-bindata@bf7910af899725e4938903fb32048c7c0b15f12e
go install github.com/elazarl/go-bindata-assetfs/go-bindata-assetfs@234c15e7648ff35458026de92b34c637bae5e6f7
go install github.com/a8m/tree/cmd/tree@fce18e2a750ea4e7f53ee706b1c3d9cbb22de79c
go install gotest.tools/gotestsum@v0.4.2
go install github.com/hashicorp/hcl/v2/cmd/hclfmt@v2.5.1
go install github.com/golang/protobuf/protoc-gen-go@v1.3.4
go install github.com/hashicorp/go-msgpack/codec/codecgen@v1.1.5
2021-04-06 15:42:44 +00:00
go install github.com/bufbuild/buf/cmd/buf@v0.36.0
Adopt go-changelog in Nomad (#10825)
Adopts [`go-changelog`](https://github.com/hashicorp/go-changelog) for managing Nomad's changelog. `go-changelog` is becoming the HashiCorp defacto standard tool for managing changelog, e.g. [Consul](https://github.com/hashicorp/consul/pull/8387), [Vault](https://github.com/hashicorp/vault/pull/10363), [Waypoint](https://github.com/hashicorp/waypoint/pull/1179). [Consul](https://github.com/hashicorp/consul/pull/8387) seems to be the first product to adopt it, and its PR has the most context - though I've updated `.changelog/README.md` with the relevant info here.
## Changes to developers workflow
When opening PRs, developers should add a changelog entry in `.changelog/<PR#>.txt`. Check [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#developer-guide).
For the WIP release, entries can be amended even after the PR merged, and new files may be added post-hoc (e.g. during transition period, missed accidentally, community PRs, etc).
### Transitioning
Pending PRs can start including the changelog entry files immediately.
For 1.1.3/1.0.9 cycle, the release coordinator should create the entries for any PR that gets merged without a changelog entry file. They should also move any 1.1.3 entry in CHANGELOG.md to a changelog entry file, as this PR done for GH-10818.
## Changes to release process
Before cutting a release, release coordinator should update the changelog by inserting the output of `make changelog` to CHANGELOG.md with appropriate headers. See [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#how-to-generate-changelog-entries-for-release) for more details.
## Details
go-changelog is a basic templating engine for maintaining changelog in HashiCorp environment.
It expects the changelog entries as files indexed by their PR number. The CLI generates the changelog section for a release by comparing two git references (e.g. `HEAD` and the latest release, e.g. `v1.1.2`), and still requires manual process for updating CHANGELOG.md and final formatting.
The approach has many nice advantages:
* Avoids changelog related merge conflicts: Each PR touches different file!
* Copes with amendments and post-PR updates: Just add or update a changelog entry file using the original PR numbers.
* Addresses the release backporting scenario: Cherry-picking PRs will cherry-pick the relevant changelog entry automatically!
* Only relies on data available through `git` - no reliance on GitHub metadata or require GitHub credentials
The approach has few downsides though:
* CHANGELOG.md going stale during development and must be updated manually before cutting the release
* Repository watchers can no longer glance at the CHANGELOG.md to see upcoming changes
* We can periodically update the file, but `go-changelog` tool does not aid with that
* `go-changelog` tool does not offer good error reporting. If an entry is has an invalid tag (e.g. uses `release-note:bugfix` instead of `release-note:bug`), the entry will be dropped silently
* We should update go-changelog to warn against unexpected entry tags
* TODO: Meanwhile, PR reviewers and release coordinators should watch out
## Potential follow ups
We should follow up with CI checks to ensure PR changes include a warning. I've opted not to include that now. We still make many non-changelog-worth PRs for website/docs, for large features that get merged in multiple small PRs. I did not want to include a check that fails often.
Also, we should follow up to have `go-changelog` emit better warnings on unexpected tag.
2021-07-06 14:46:53 +00:00
go install github.com/hashicorp/go-changelog/cmd/changelog-build@latest
2022-01-06 16:56:13 +00:00
go install golang.org/x/tools/cmd/stringer@v0.1.8
2017-08-18 05:29:26 +00:00
2017-10-24 17:49:53 +00:00
.PHONY : lint -deps
lint-deps : ## Install linter dependencies
2020-05-30 14:29:47 +00:00
## Keep versions in sync with tools/go.mod (see https://github.com/golang/go/issues/30515)
2017-10-24 17:49:53 +00:00
@echo "==> Updating linter dependencies..."
2021-08-31 09:13:31 +00:00
go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.42.0
2021-03-09 18:49:48 +00:00
go install github.com/client9/misspell/cmd/misspell@v0.3.4
go install github.com/hashicorp/go-hclog/hclogvet@v0.1.3
2017-10-24 17:49:53 +00:00
2019-04-17 22:28:17 +00:00
.PHONY : git -hooks
git-dir = $( shell git rev-parse --git-dir)
git-hooks : $( git -dir ) /hooks /pre -push
$(git-dir)/hooks/% : dev /hooks /%
cp $^ $@
chmod 755 $@
2017-08-18 05:29:26 +00:00
.PHONY : check
check : ## Lint the source code
@echo "==> Linting source code..."
2019-08-16 13:11:31 +00:00
@golangci-lint run -j 1
2020-08-27 20:21:07 +00:00
2020-07-01 14:08:37 +00:00
@echo "==> Linting hclog statements..."
@hclogvet .
2019-12-06 01:27:14 +00:00
2017-09-27 18:14:37 +00:00
@echo "==> Spell checking website..."
2020-04-23 14:38:08 +00:00
@misspell -error -source= text website/pages/
2017-08-18 05:29:26 +00:00
2020-11-17 15:01:48 +00:00
@echo "==> Checking for breaking changes in protos..."
2021-02-01 01:09:15 +00:00
@buf breaking --config tools/buf/buf.yaml --against-config tools/buf/buf.yaml --against .git#tag= $( PROTO_COMPARE_TAG)
2020-11-17 15:01:48 +00:00
2019-03-14 14:56:27 +00:00
@echo "==> Check proto files are in-sync..."
@$( MAKE) proto
2020-04-23 18:32:44 +00:00
@if ( git status -s | grep -q .pb.go) ; then echo the following proto files are out of sync; git status -s | grep .pb.go; exit 1; fi
@echo "==> Check format of jobspecs and HCL files..."
@$( MAKE) hclfmt
2021-09-01 19:15:06 +00:00
@if ( git status -s | grep -q -e '\.hcl$$' -e '\.nomad$$' -e '\.tf$$' ) ; then echo the following HCL files are out of sync; git status -s | grep -e '\.hcl$$' -e '\.nomad$$' -e '\.tf$$' ; exit 1; fi
2019-03-14 14:56:27 +00:00
2019-04-28 17:31:43 +00:00
@echo "==> Check API package is isolated from rest"
2021-07-14 16:07:16 +00:00
@cd ./api && if go list --test -f '{{ join .Deps "\n" }}' . | grep github.com/hashicorp/nomad/ | grep -v -e /nomad/api/ -e nomad/api.test; then echo " /api package depends the ^^ above internal nomad packages. Remove such dependency" ; exit 1; fi
2020-03-09 19:06:47 +00:00
2020-08-27 20:21:07 +00:00
@echo "==> Checking Go mod.."
2021-07-14 16:07:16 +00:00
@GO111MODULE= on $( MAKE) tidy
2020-08-27 20:21:07 +00:00
@if ( git status --porcelain | grep -Eq "go\.(mod|sum)" ) ; then \
echo go.mod or go.sum needs updating; \
git --no-pager diff go.mod; \
git --no-pager diff go.sum; \
exit 1; fi
2020-08-31 11:59:16 +00:00
@echo "==> Check raft util msg type mapping are in-sync..."
@go generate ./helper/raftutil/
@if ( git status -s ./helper/raftutil| grep -q .go) ; then echo "raftutil helper message type mapping is out of sync. Run go generate ./... and push." ; exit 1; fi
2017-09-09 00:42:42 +00:00
.PHONY : checkscripts
checkscripts : ## Lint shell scripts
@echo "==> Linting scripts..."
2019-03-18 12:45:25 +00:00
@find scripts -type f -name '*.sh' | xargs shellcheck
2017-09-09 00:42:42 +00:00
2020-11-20 14:26:02 +00:00
.PHONY : checkproto
checkproto : ## Lint protobuf files
2020-11-20 14:49:43 +00:00
@echo "==> Lint proto files..."
@buf check lint --config tools/buf/buf.yaml
2020-11-20 14:26:02 +00:00
@echo "==> Checking for breaking changes in protos..."
@buf check breaking --config tools/buf/buf.yaml --against-config tools/buf/buf.yaml --against .git#tag= $( PROTO_COMPARE_TAG)
2018-11-07 19:51:03 +00:00
.PHONY : generate -all
2019-08-14 14:23:33 +00:00
generate-all : generate -structs proto generate -examples
2018-11-07 19:51:03 +00:00
.PHONY : generate -structs
2021-07-14 16:07:16 +00:00
generate-structs : LOCAL_PACKAGES = $( shell go list ./...)
2018-11-07 19:51:03 +00:00
generate-structs : ## Update generated code
2019-01-30 16:00:17 +00:00
@echo "--> Running go generate..."
2017-08-18 05:29:26 +00:00
@go generate $( LOCAL_PACKAGES)
2018-09-28 17:09:01 +00:00
.PHONY : proto
proto :
2019-01-30 16:00:17 +00:00
@echo "--> Generating proto bindings..."
2020-11-17 15:01:48 +00:00
@buf --config tools/buf/buf.yaml --template tools/buf/buf.gen.yaml generate
2018-09-28 17:09:01 +00:00
2019-08-14 14:23:33 +00:00
.PHONY : generate -examples
generate-examples : command /job_init .bindata_assetfs .go
command/job_init.bindata_assetfs.go : command /assets /*
go-bindata-assetfs -pkg command -o command/job_init.bindata_assetfs.go ./command/assets/...
2018-09-28 17:09:01 +00:00
Adopt go-changelog in Nomad (#10825)
Adopts [`go-changelog`](https://github.com/hashicorp/go-changelog) for managing Nomad's changelog. `go-changelog` is becoming the HashiCorp defacto standard tool for managing changelog, e.g. [Consul](https://github.com/hashicorp/consul/pull/8387), [Vault](https://github.com/hashicorp/vault/pull/10363), [Waypoint](https://github.com/hashicorp/waypoint/pull/1179). [Consul](https://github.com/hashicorp/consul/pull/8387) seems to be the first product to adopt it, and its PR has the most context - though I've updated `.changelog/README.md` with the relevant info here.
## Changes to developers workflow
When opening PRs, developers should add a changelog entry in `.changelog/<PR#>.txt`. Check [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#developer-guide).
For the WIP release, entries can be amended even after the PR merged, and new files may be added post-hoc (e.g. during transition period, missed accidentally, community PRs, etc).
### Transitioning
Pending PRs can start including the changelog entry files immediately.
For 1.1.3/1.0.9 cycle, the release coordinator should create the entries for any PR that gets merged without a changelog entry file. They should also move any 1.1.3 entry in CHANGELOG.md to a changelog entry file, as this PR done for GH-10818.
## Changes to release process
Before cutting a release, release coordinator should update the changelog by inserting the output of `make changelog` to CHANGELOG.md with appropriate headers. See [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#how-to-generate-changelog-entries-for-release) for more details.
## Details
go-changelog is a basic templating engine for maintaining changelog in HashiCorp environment.
It expects the changelog entries as files indexed by their PR number. The CLI generates the changelog section for a release by comparing two git references (e.g. `HEAD` and the latest release, e.g. `v1.1.2`), and still requires manual process for updating CHANGELOG.md and final formatting.
The approach has many nice advantages:
* Avoids changelog related merge conflicts: Each PR touches different file!
* Copes with amendments and post-PR updates: Just add or update a changelog entry file using the original PR numbers.
* Addresses the release backporting scenario: Cherry-picking PRs will cherry-pick the relevant changelog entry automatically!
* Only relies on data available through `git` - no reliance on GitHub metadata or require GitHub credentials
The approach has few downsides though:
* CHANGELOG.md going stale during development and must be updated manually before cutting the release
* Repository watchers can no longer glance at the CHANGELOG.md to see upcoming changes
* We can periodically update the file, but `go-changelog` tool does not aid with that
* `go-changelog` tool does not offer good error reporting. If an entry is has an invalid tag (e.g. uses `release-note:bugfix` instead of `release-note:bug`), the entry will be dropped silently
* We should update go-changelog to warn against unexpected entry tags
* TODO: Meanwhile, PR reviewers and release coordinators should watch out
## Potential follow ups
We should follow up with CI checks to ensure PR changes include a warning. I've opted not to include that now. We still make many non-changelog-worth PRs for website/docs, for large features that get merged in multiple small PRs. I did not want to include a check that fails often.
Also, we should follow up to have `go-changelog` emit better warnings on unexpected tag.
2021-07-06 14:46:53 +00:00
changelog :
@changelog-build -last-release $( LAST_RELEASE) -this-release HEAD \
-entries-dir .changelog/ -changelog-template ./.changelog/changelog.tmpl -note-template ./.changelog/note.tmpl
2017-12-12 21:52:58 +00:00
2019-08-05 12:07:43 +00:00
## We skip the terraform directory as there are templated hcl configurations
## that do not successfully compile without rendering
.PHONY : hclfmt
hclfmt :
@echo "--> Formatting HCL"
2021-09-01 19:15:06 +00:00
@find . -name '.terraform' -prune \
-o -name 'upstart.nomad' -prune \
-o -name '.git' -prune \
-o -name 'node_modules' -prune \
-o -name '.next' -prune \
-o -path './ui/dist' -prune \
-o -path './website/out' -prune \
-o \( -name '*.nomad' -o -name '*.hcl' -o -name '*.tf' \) \
-print0 | xargs -0 hclfmt -w
2017-12-12 16:30:36 +00:00
2020-05-30 14:29:47 +00:00
.PHONY : tidy
tidy :
@echo "--> Tidy up submodules"
@cd tools && go mod tidy
@cd api && go mod tidy
@echo "--> Tidy nomad module"
@go mod tidy
2017-08-18 05:29:26 +00:00
.PHONY : dev
dev : GOOS =$( shell go env GOOS )
dev : GOARCH =$( shell go env GOARCH )
2019-01-08 01:39:29 +00:00
dev : DEV_TARGET =pkg /$( GOOS ) _ $( GOARCH ) /nomad
Adopt go-changelog in Nomad (#10825)
Adopts [`go-changelog`](https://github.com/hashicorp/go-changelog) for managing Nomad's changelog. `go-changelog` is becoming the HashiCorp defacto standard tool for managing changelog, e.g. [Consul](https://github.com/hashicorp/consul/pull/8387), [Vault](https://github.com/hashicorp/vault/pull/10363), [Waypoint](https://github.com/hashicorp/waypoint/pull/1179). [Consul](https://github.com/hashicorp/consul/pull/8387) seems to be the first product to adopt it, and its PR has the most context - though I've updated `.changelog/README.md` with the relevant info here.
## Changes to developers workflow
When opening PRs, developers should add a changelog entry in `.changelog/<PR#>.txt`. Check [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#developer-guide).
For the WIP release, entries can be amended even after the PR merged, and new files may be added post-hoc (e.g. during transition period, missed accidentally, community PRs, etc).
### Transitioning
Pending PRs can start including the changelog entry files immediately.
For 1.1.3/1.0.9 cycle, the release coordinator should create the entries for any PR that gets merged without a changelog entry file. They should also move any 1.1.3 entry in CHANGELOG.md to a changelog entry file, as this PR done for GH-10818.
## Changes to release process
Before cutting a release, release coordinator should update the changelog by inserting the output of `make changelog` to CHANGELOG.md with appropriate headers. See [`.changelog/README.md`](https://github.com/hashicorp/nomad/blob/docs-adopt-gochangelog/.changelog/README.md#how-to-generate-changelog-entries-for-release) for more details.
## Details
go-changelog is a basic templating engine for maintaining changelog in HashiCorp environment.
It expects the changelog entries as files indexed by their PR number. The CLI generates the changelog section for a release by comparing two git references (e.g. `HEAD` and the latest release, e.g. `v1.1.2`), and still requires manual process for updating CHANGELOG.md and final formatting.
The approach has many nice advantages:
* Avoids changelog related merge conflicts: Each PR touches different file!
* Copes with amendments and post-PR updates: Just add or update a changelog entry file using the original PR numbers.
* Addresses the release backporting scenario: Cherry-picking PRs will cherry-pick the relevant changelog entry automatically!
* Only relies on data available through `git` - no reliance on GitHub metadata or require GitHub credentials
The approach has few downsides though:
* CHANGELOG.md going stale during development and must be updated manually before cutting the release
* Repository watchers can no longer glance at the CHANGELOG.md to see upcoming changes
* We can periodically update the file, but `go-changelog` tool does not aid with that
* `go-changelog` tool does not offer good error reporting. If an entry is has an invalid tag (e.g. uses `release-note:bugfix` instead of `release-note:bug`), the entry will be dropped silently
* We should update go-changelog to warn against unexpected entry tags
* TODO: Meanwhile, PR reviewers and release coordinators should watch out
## Potential follow ups
We should follow up with CI checks to ensure PR changes include a warning. I've opted not to include that now. We still make many non-changelog-worth PRs for website/docs, for large features that get merged in multiple small PRs. I did not want to include a check that fails often.
Also, we should follow up to have `go-changelog` emit better warnings on unexpected tag.
2021-07-06 14:46:53 +00:00
dev : hclfmt ## Build for the current development platform
2017-08-18 05:29:26 +00:00
@echo "==> Removing old development build..."
@rm -f $( PROJECT_ROOT) /$( DEV_TARGET)
@rm -f $( PROJECT_ROOT) /bin/nomad
@rm -f $( GOPATH) /bin/nomad
2021-10-14 15:32:19 +00:00
@if [ -d vendor ] ; then echo -e "==> WARNING: Found vendor directory. This may cause build errors, consider running 'rm -r vendor' or 'make clean' to remove.\n" ; fi
2017-08-18 05:29:26 +00:00
@$( MAKE) --no-print-directory \
$( DEV_TARGET) \
2019-08-02 15:55:52 +00:00
GO_TAGS = " $( GO_TAGS) $( NOMAD_UI_TAG) "
2017-08-18 05:29:26 +00:00
@mkdir -p $( PROJECT_ROOT) /bin
@mkdir -p $( GOPATH) /bin
@cp $( PROJECT_ROOT) /$( DEV_TARGET) $( PROJECT_ROOT) /bin/
@cp $( PROJECT_ROOT) /$( DEV_TARGET) $( GOPATH) /bin
2017-10-26 17:08:19 +00:00
.PHONY : prerelease
dev: avoid codecgen code in downstream projects
This is an attempt to ease dependency management for external driver
plugins, by avoiding requiring them to compile ugorji/go generated
files. Plugin developers reported some pain with the brittleness of
ugorji/go dependency in particular, specially when using go mod, the
default go mod manager in golang 1.13.
Context
--------
Nomad uses msgpack to persist and serialize internal structs, using
ugorji/go library. As an optimization, we use ugorji/go code generation
to speedup process and aovid the relection-based slow path.
We commit these generated files in repository when we cut and tag the
release to ease reproducability and debugging old releases. Thus,
downstream projects that depend on release tag, indirectly depends on
ugorji/go generated code.
Sadly, the generated code is brittle and specific to the version of
ugorji/go being used. When go mod picks another version of ugorji/go
then nomad (go mod by default uses release according to semver),
downstream projects face compilation errors.
Interestingly, downstream projects don't commonly serialize nomad
internal structs. Drivers and device plugins use grpc instead of
msgpack for the most part. In the few cases where they use msgpag (e.g.
decoding task config), they do without codegen path as they run on
driver specific structs not the nomad internal structs. Also, the
ugorji/go serialization through reflection is generally backward
compatible (mod some ugorji/go regression bugs that get introduced every
now and then :( ).
Proposal
---------
The proposal here is to keep committing ugorji/go codec generated files
for releases but to use a go tag for them.
All nomad development through the makefile, including releasing, CI and
dev flow, has the tag enabled.
Downstream plugin projects, by default, will skip these files and life
proceed as normal for them.
The downside is that nomad developers who use generated code but avoid
using make must start passing additional go tag argument. Though this
is not a blessed configuration.
2019-09-06 12:43:26 +00:00
prerelease : GO_TAGS =ui codegen_generated release
2019-03-21 18:57:03 +00:00
prerelease : generate -all ember -dist static -assets ## Generate all the static assets for a Nomad release
2017-10-26 17:08:19 +00:00
2017-08-18 05:29:26 +00:00
.PHONY : release
dev: avoid codecgen code in downstream projects
This is an attempt to ease dependency management for external driver
plugins, by avoiding requiring them to compile ugorji/go generated
files. Plugin developers reported some pain with the brittleness of
ugorji/go dependency in particular, specially when using go mod, the
default go mod manager in golang 1.13.
Context
--------
Nomad uses msgpack to persist and serialize internal structs, using
ugorji/go library. As an optimization, we use ugorji/go code generation
to speedup process and aovid the relection-based slow path.
We commit these generated files in repository when we cut and tag the
release to ease reproducability and debugging old releases. Thus,
downstream projects that depend on release tag, indirectly depends on
ugorji/go generated code.
Sadly, the generated code is brittle and specific to the version of
ugorji/go being used. When go mod picks another version of ugorji/go
then nomad (go mod by default uses release according to semver),
downstream projects face compilation errors.
Interestingly, downstream projects don't commonly serialize nomad
internal structs. Drivers and device plugins use grpc instead of
msgpack for the most part. In the few cases where they use msgpag (e.g.
decoding task config), they do without codegen path as they run on
driver specific structs not the nomad internal structs. Also, the
ugorji/go serialization through reflection is generally backward
compatible (mod some ugorji/go regression bugs that get introduced every
now and then :( ).
Proposal
---------
The proposal here is to keep committing ugorji/go codec generated files
for releases but to use a go tag for them.
All nomad development through the makefile, including releasing, CI and
dev flow, has the tag enabled.
Downstream plugin projects, by default, will skip these files and life
proceed as normal for them.
The downside is that nomad developers who use generated code but avoid
using make must start passing additional go tag argument. Though this
is not a blessed configuration.
2019-09-06 12:43:26 +00:00
release : GO_TAGS =ui codegen_generated release
2017-10-26 17:08:19 +00:00
release : clean $( foreach t ,$ ( ALL_TARGETS ) ,pkg /$ ( t ) .zip ) ## Build all release packages which can be built on this platform.
2017-08-18 05:29:26 +00:00
@echo "==> Results:"
@tree --dirsfirst $( PROJECT_ROOT) /pkg
.PHONY : test
2017-09-19 14:47:10 +00:00
test : ## Run the Nomad test suite and/or the Nomad UI test suite
@if [ ! $( SKIP_NOMAD_TESTS) ] ; then \
make test-nomad; \
fi
2018-10-08 18:44:23 +00:00
@if [ $( RUN_WEBSITE_TESTS) ] ; then \
make test-website; \
fi
2017-09-19 14:47:10 +00:00
@if [ $( RUN_UI_TESTS) ] ; then \
make test-ui; \
fi
2018-09-19 17:21:57 +00:00
@if [ $( RUN_E2E_TESTS) ] ; then \
make e2e-test; \
fi
2017-09-19 14:47:10 +00:00
.PHONY : test -nomad
2017-10-24 16:35:51 +00:00
test-nomad : dev ## Run Nomad test suites
2017-08-18 05:29:26 +00:00
@echo "==> Running Nomad test suites:"
2018-12-15 19:00:27 +00:00
$( if $( ENABLE_RACE) ,GORACE= " strip_path_prefix= $( GOPATH) /src " ) $( GO_TEST_CMD) \
2018-08-27 21:15:56 +00:00
$( if $( ENABLE_RACE) ,-race) $( if $( VERBOSE) ,-v) \
-cover \
2018-12-08 19:50:47 +00:00
-timeout= 15m \
dev: avoid codecgen code in downstream projects
This is an attempt to ease dependency management for external driver
plugins, by avoiding requiring them to compile ugorji/go generated
files. Plugin developers reported some pain with the brittleness of
ugorji/go dependency in particular, specially when using go mod, the
default go mod manager in golang 1.13.
Context
--------
Nomad uses msgpack to persist and serialize internal structs, using
ugorji/go library. As an optimization, we use ugorji/go code generation
to speedup process and aovid the relection-based slow path.
We commit these generated files in repository when we cut and tag the
release to ease reproducability and debugging old releases. Thus,
downstream projects that depend on release tag, indirectly depends on
ugorji/go generated code.
Sadly, the generated code is brittle and specific to the version of
ugorji/go being used. When go mod picks another version of ugorji/go
then nomad (go mod by default uses release according to semver),
downstream projects face compilation errors.
Interestingly, downstream projects don't commonly serialize nomad
internal structs. Drivers and device plugins use grpc instead of
msgpack for the most part. In the few cases where they use msgpag (e.g.
decoding task config), they do without codegen path as they run on
driver specific structs not the nomad internal structs. Also, the
ugorji/go serialization through reflection is generally backward
compatible (mod some ugorji/go regression bugs that get introduced every
now and then :( ).
Proposal
---------
The proposal here is to keep committing ugorji/go codec generated files
for releases but to use a go tag for them.
All nomad development through the makefile, including releasing, CI and
dev flow, has the tag enabled.
Downstream plugin projects, by default, will skip these files and life
proceed as normal for them.
The downside is that nomad developers who use generated code but avoid
using make must start passing additional go tag argument. Though this
is not a blessed configuration.
2019-09-06 12:43:26 +00:00
-tags " $( GO_TAGS) " \
2019-05-10 14:14:18 +00:00
$( GOTEST_PKGS) $( if $( VERBOSE) , >test.log ; echo $$ ? > exit-code)
@if [ $( VERBOSE) ] ; then \
bash -C " $( PROJECT_ROOT) /scripts/test_check.sh " ; \
fi
2017-08-18 05:29:26 +00:00
2020-05-30 14:29:47 +00:00
.PHONY : test -nomad -module
test-nomad-module : dev ## Run Nomad test suites on a sub-module
2022-01-18 18:17:37 +00:00
@echo " ==> Running Nomad test suites on sub-module $( GOTEST_MOD) "
2020-05-30 14:29:47 +00:00
@cd $( GOTEST_MOD) && $( if $( ENABLE_RACE) ,GORACE= " strip_path_prefix= $( GOPATH) /src " ) $( GO_TEST_CMD) \
$( if $( ENABLE_RACE) ,-race) $( if $( VERBOSE) ,-v) \
-cover \
-timeout= 15m \
-tags " $( GO_TAGS) " \
./... $( if $( VERBOSE) , >test.log ; echo $$ ? > exit-code)
@if [ $( VERBOSE) ] ; then \
bash -C " $( PROJECT_ROOT) /scripts/test_check.sh " ; \
fi
2018-09-19 01:46:33 +00:00
.PHONY : e 2e -test
2018-09-19 17:38:20 +00:00
e2e-test : dev ## Run the Nomad e2e test suite
2018-09-19 01:46:33 +00:00
@echo "==> Running Nomad E2E test suites:"
2020-10-14 18:53:21 +00:00
go test \
$( if $( ENABLE_RACE) ,-race) $( if $( VERBOSE) ,-v) \
-timeout= 900s \
-tags " $( GO_TAGS) " \
github.com/hashicorp/nomad/e2e
.PHONY : integration -test
integration-test : dev ## Run Nomad integration tests
@echo "==> Running Nomad integration test suites:"
2018-09-19 01:46:33 +00:00
go test \
$( if $( ENABLE_RACE) ,-race) $( if $( VERBOSE) ,-v) \
-cover \
-timeout= 900s \
dev: avoid codecgen code in downstream projects
This is an attempt to ease dependency management for external driver
plugins, by avoiding requiring them to compile ugorji/go generated
files. Plugin developers reported some pain with the brittleness of
ugorji/go dependency in particular, specially when using go mod, the
default go mod manager in golang 1.13.
Context
--------
Nomad uses msgpack to persist and serialize internal structs, using
ugorji/go library. As an optimization, we use ugorji/go code generation
to speedup process and aovid the relection-based slow path.
We commit these generated files in repository when we cut and tag the
release to ease reproducability and debugging old releases. Thus,
downstream projects that depend on release tag, indirectly depends on
ugorji/go generated code.
Sadly, the generated code is brittle and specific to the version of
ugorji/go being used. When go mod picks another version of ugorji/go
then nomad (go mod by default uses release according to semver),
downstream projects face compilation errors.
Interestingly, downstream projects don't commonly serialize nomad
internal structs. Drivers and device plugins use grpc instead of
msgpack for the most part. In the few cases where they use msgpag (e.g.
decoding task config), they do without codegen path as they run on
driver specific structs not the nomad internal structs. Also, the
ugorji/go serialization through reflection is generally backward
compatible (mod some ugorji/go regression bugs that get introduced every
now and then :( ).
Proposal
---------
The proposal here is to keep committing ugorji/go codec generated files
for releases but to use a go tag for them.
All nomad development through the makefile, including releasing, CI and
dev flow, has the tag enabled.
Downstream plugin projects, by default, will skip these files and life
proceed as normal for them.
The downside is that nomad developers who use generated code but avoid
using make must start passing additional go tag argument. Though this
is not a blessed configuration.
2019-09-06 12:43:26 +00:00
-tags " $( GO_TAGS) " \
2020-10-14 12:43:28 +00:00
github.com/hashicorp/nomad/e2e/vaultcompat/ \
2018-09-25 18:29:09 +00:00
-integration
2018-09-19 01:46:33 +00:00
2017-08-18 05:29:26 +00:00
.PHONY : clean
clean : GOPATH =$( shell go env GOPATH )
clean : ## Remove build artifacts
@echo "==> Cleaning build artifacts..."
@rm -rf " $( PROJECT_ROOT) /bin/ "
@rm -rf " $( PROJECT_ROOT) /pkg/ "
2021-10-14 15:32:19 +00:00
@rm -rf " $( PROJECT_ROOT) /vendor/ "
2017-08-18 05:29:26 +00:00
@rm -f " $( GOPATH) /bin/nomad "
2017-09-07 18:49:22 +00:00
.PHONY : testcluster
testcluster : ## Bring up a Linux test cluster using Vagrant. Set PROVIDER if necessary.
vagrant up nomad-server01 \
nomad-server02 \
nomad-server03 \
nomad-client01 \
nomad-client02 \
nomad-client03 \
$( if $( PROVIDER) ,--provider $( PROVIDER) )
2017-09-19 14:47:10 +00:00
.PHONY : static -assets
static-assets : ## Compile the static routes to serve alongside the API
@echo "--> Generating static assets"
2018-03-19 22:49:25 +00:00
@go-bindata-assetfs -pkg agent -prefix ui -modtime 1480000000 -tags ui -o bindata_assetfs.go ./ui/dist/...
2017-09-19 14:47:10 +00:00
@mv bindata_assetfs.go command/agent
.PHONY : test -ui
2017-11-13 19:57:17 +00:00
test-ui : ## Run Nomad UI test suite
2017-09-19 14:47:10 +00:00
@echo "--> Installing JavaScript assets"
2017-12-14 01:04:15 +00:00
@cd ui && npm rebuild node-sass
2017-09-19 14:47:10 +00:00
@cd ui && yarn install
@echo "--> Running ember tests"
@cd ui && npm test
.PHONY : ember -dist
ember-dist : ## Build the static UI assets from source
@echo "--> Installing JavaScript assets"
2018-03-20 18:30:09 +00:00
@cd ui && yarn install --silent
2017-09-19 14:47:10 +00:00
@cd ui && npm rebuild node-sass
@echo "--> Building Ember application"
@cd ui && npm run build
.PHONY : dev -ui
dev-ui : ember -dist static -assets
@$( MAKE) NOMAD_UI_TAG = "ui" dev ## Build a dev binary with the UI baked in
2017-08-18 05:29:26 +00:00
HELP_FORMAT = " \033[36m%-25s\033[0m %s\n"
.PHONY : help
help : ## Display this usage information
@echo "Valid targets:"
@grep -E '^[^ ]+:.*?## .*$$' $( MAKEFILE_LIST) | \
sort | \
awk ' BEGIN { FS = ":.*?## " } ; \
{ printf $( HELP_FORMAT) , $$ 1, $$ 2} '
2017-11-13 19:57:17 +00:00
@echo ""
@echo "This host will build the following targets if 'make release' is invoked:"
2017-08-18 05:29:26 +00:00
@echo $( ALL_TARGETS) | sed 's/^/ /'
2019-06-20 00:20:13 +00:00
2019-08-12 16:39:54 +00:00
.PHONY : ui -screenshots
2019-06-20 00:20:13 +00:00
ui-screenshots :
@echo "==> Collecting UI screenshots..."
2020-05-30 14:29:47 +00:00
# Build the screenshots image if it doesn't exist yet
2019-06-20 00:20:13 +00:00
@if [ [ " $$ (docker images -q nomad-ui-screenshots 2> /dev/null) " = = "" ] ] ; then \
docker build --tag= "nomad-ui-screenshots" ./scripts/screenshots; \
fi
@docker run \
--rm \
--volume " $( shell pwd ) /scripts/screenshots/screenshots:/screenshots " \
nomad-ui-screenshots
2019-08-12 16:39:54 +00:00
.PHONY : ui -screenshots -local
2019-06-20 00:20:13 +00:00
ui-screenshots-local :
@echo "==> Collecting UI screenshots (local)..."
2019-08-02 15:55:52 +00:00
@cd scripts/screenshots/src && SCREENSHOTS_DIR = "../screenshots" node index.js