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
2022-02-16 17:59:50 +00:00
GOPATH := $( shell go env GOPATH | cut -d: -f1)
e n d i f
# Respect $GOBIN if set in environment or via $GOENV file.
BIN := $( shell go env GOBIN)
i f n d e f B I N
2022-02-17 13:48:39 +00:00
BIN := $( GOPATH) /bin
2022-01-18 18:17:37 +00:00
e n d i f
2022-09-29 14:30:13 +00:00
GO_TAGS := $( GO_TAGS)
2021-04-01 20:27:18 +00:00
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-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
2022-04-25 15:57:55 +00:00
# published release, and release branches should point to the latest published release in the X.Y release line.
2022-10-20 17:09:41 +00:00
LAST_RELEASE ?= v1.4.1
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
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 ) )
2022-04-06 15:47:02 +00:00
ALL_TARGETS = darwin_amd64 \
darwin_arm64
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
2022-10-19 17:27:47 +00:00
# Allow overriding ALL_TARGETS via $TARGETS
i f d e f T A R G E T S
ALL_TARGETS = $( TARGETS)
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
2022-10-21 13:45:24 +00:00
go install gotest.tools/gotestsum@v1.8.2
2022-05-16 23:15:41 +00:00
go install github.com/hashicorp/hcl/v2/cmd/hclfmt@d0c4fa8b0bbc2e4eeccd1ed2a32c2089ed8c5cf1
2021-03-09 18:49:48 +00:00
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-08-01 14:50:58 +00:00
go install golang.org/x/tools/cmd/stringer@v0.1.12
2022-10-04 12:22:30 +00:00
go install github.com/hashicorp/hc-install/cmd/hc-install@4487b02cbcbb92204e3416cef9852b6ad44487b2
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..."
2022-08-16 20:06:06 +00:00
go install github.com/golangci/golangci-lint/cmd/golangci-lint@v1.48.0
2021-03-09 18:49:48 +00:00
go install github.com/client9/misspell/cmd/misspell@v0.3.4
2022-08-17 16:26:34 +00:00
go install github.com/hashicorp/go-hclog/hclogvet@v0.1.5
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..."
2022-02-14 22:54:24 +00:00
@golangci-lint run
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
2022-08-02 14:33:08 +00:00
@echo "==> Check command package does not import structs"
@cd ./command && if go list -f '{{ join .Imports "\n" }}' . | grep github.com/hashicorp/nomad/nomad/structs; then echo " /command package imports the structs pkg. Remove such import" ; exit 1; fi
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
2022-04-21 19:57:16 +00:00
generate-all : generate -structs proto generate -examples ## Generate structs, protobufs, 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
2022-08-14 16:19:53 +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
2022-04-21 19:57:16 +00:00
proto : ## Generate protobuf bindings
2022-08-14 16:19:53 +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
2022-04-21 19:57:16 +00:00
changelog : ## Generate changelog from entries
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-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
2022-04-21 19:57:16 +00:00
hclfmt : ## Format HCL files with hclfmt
2022-08-14 16:19:53 +00:00
@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 \
2022-10-06 21:00:29 +00:00
-o -path './command/testdata' -prune \
2021-09-01 19:15:06 +00:00
-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
2022-04-21 19:57:16 +00:00
tidy : ## Tidy up the go mod files
2022-08-14 16:19:53 +00:00
@echo "==> Tidy up submodules"
2020-05-30 14:29:47 +00:00
@cd tools && go mod tidy
@cd api && go mod tidy
2022-08-14 16:19:53 +00:00
@echo "==> Tidy nomad module"
2020-05-30 14:29:47 +00:00
@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
2022-02-16 17:59:50 +00:00
@rm -f $( 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
2022-02-16 17:59:50 +00:00
@mkdir -p $( BIN)
2017-08-18 05:29:26 +00:00
@cp $( PROJECT_ROOT) /$( DEV_TARGET) $( PROJECT_ROOT) /bin/
2022-02-16 17:59:50 +00:00
@cp $( PROJECT_ROOT) /$( DEV_TARGET) $( BIN)
2017-08-18 05:29:26 +00:00
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
2017-09-19 14:47:10 +00:00
.PHONY : test -nomad
2022-10-27 14:02:58 +00:00
test-nomad : GOTEST_PKGS =$( shell go run -modfile =tools /go .mod tools /missing /main .go ci /test -core .json $ ( GOTEST_GROUP ) )
test-nomad : # dev ## Run Nomad unit tests
@echo " ==> Running Nomad unit tests $( GOTEST_GROUP) "
@echo " ==> with packages $( GOTEST_PKGS) "
gotestsum --format= testname --rerun-fails= 3 --packages= " $( GOTEST_PKGS) " -- \
2018-08-27 21:15:56 +00:00
-cover \
2022-02-28 16:30:59 +00:00
-timeout= 20m \
2022-03-24 23:49:51 +00:00
-count= 1 \
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) " \
2022-03-24 19:58:43 +00:00
$( GOTEST_PKGS)
2017-08-18 05:29:26 +00:00
2020-05-30 14:29:47 +00:00
.PHONY : test -nomad -module
2022-10-21 13:45:24 +00:00
test-nomad-module : dev ## Run Nomad unit tests on sub-module
@echo " ==> Running Nomad unit tests on sub-module $( GOTEST_MOD) "
cd $( GOTEST_MOD) ; gotestsum --format= testname --rerun-fails= 3 --packages= ./... -- \
2020-05-30 14:29:47 +00:00
-cover \
2022-02-28 16:30:59 +00:00
-timeout= 20m \
2022-03-24 23:49:51 +00:00
-count= 1 \
2020-05-30 14:29:47 +00:00
-tags " $( GO_TAGS) " \
2022-03-24 19:58:43 +00:00
./...
2020-05-30 14:29:47 +00:00
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/ "
2022-02-16 17:59:50 +00:00
@rm -f " $( BIN) /nomad "
2017-08-18 05:29:26 +00:00
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
2022-08-14 16:19:53 +00:00
@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
2022-08-14 16:19:53 +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
2022-08-14 16:19:53 +00:00
@echo "==> Running ember tests"
2017-09-19 14:47:10 +00:00
@cd ui && npm test
.PHONY : ember -dist
ember-dist : ## Build the static UI assets from source
2022-08-14 16:19:53 +00:00
@echo "==> Installing JavaScript assets"
2022-04-06 15:47:02 +00:00
@cd ui && yarn install --silent --network-timeout 300000
2017-09-19 14:47:10 +00:00
@cd ui && npm rebuild node-sass
2022-08-14 16:19:53 +00:00
@echo "==> Building Ember application"
2017-09-19 14:47:10 +00:00
@cd ui && npm run build
.PHONY : dev -ui
2022-04-21 19:57:16 +00:00
dev-ui : ember -dist static -assets ## Build a dev UI binary
2017-09-19 14:47:10 +00:00
@$( 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
2022-04-21 19:57:16 +00:00
ui-screenshots : ## Collect UI screenshots
2019-06-20 00:20:13 +00:00
@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
2022-04-21 19:57:16 +00:00
ui-screenshots-local : ## Collect UI screenshots (local)
2019-06-20 00:20:13 +00:00
@echo "==> Collecting UI screenshots (local)..."
2019-08-02 15:55:52 +00:00
@cd scripts/screenshots/src && SCREENSHOTS_DIR = "../screenshots" node index.js
2022-04-06 15:47:02 +00:00
2022-03-19 21:29:32 +00:00
.PHONY : version
2022-04-21 19:57:16 +00:00
version : ## Lookup the current build version
2022-04-06 15:47:02 +00:00
i f n e q ( , $( wildcard version /version_ent .go ) )
2022-04-06 16:56:52 +00:00
@$( CURDIR) /scripts/version.sh version/version.go version/version_ent.go
2022-04-06 15:47:02 +00:00
e l s e
2022-04-06 16:56:52 +00:00
@$( CURDIR) /scripts/version.sh version/version.go version/version.go
2022-04-06 15:47:02 +00:00
e n d i f
2022-03-19 21:29:32 +00:00
.PHONY : missing
2022-04-21 19:57:16 +00:00
missing : ## Check for packages not being tested
2022-03-19 21:29:32 +00:00
@echo "==> Checking for packages not being tested ..."
2022-10-27 14:02:58 +00:00
@go run -modfile tools/go.mod tools/missing/main.go ci/test-core.json
2022-09-09 12:17:02 +00:00
.PHONY : ec 2info
ec2info : ## Generate AWS EC2 CPU specification table
@echo "==> Generating AWS EC2 specifications ..."
@go run -modfile tools/go.mod tools/ec2info/main.go