94913d2ad6
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. |
||
---|---|---|
.. | ||
CHANGELOG.md | ||
checklist-command.md | ||
checklist-jobspec.md | ||
checklist-rpc-endpoint.md | ||
golang.md | ||
issue-labels.md | ||
README.md |
Nomad Codebase Documentation
This directory contains some documentation about the Nomad codebase, aimed at readers who are interested in making code contributions.
If you're looking for information on using Nomad, please instead refer to the Nomad website.
Developing with Vagrant
A development environment is supplied via Vagrant to make getting started easier.
-
Install Vagrant
-
Install Virtualbox
-
Bring up the Vagrant project
$ git clone https://github.com/hashicorp/nomad.git $ cd nomad $ vagrant up
The virtual machine will launch, and a provisioning script will install the needed dependencies within the VM.
-
SSH into the VM
$ vagrant ssh
Developing without Vagrant
- Install Go 1.16.5+ (Note:
gcc-go
is not supported) - Clone this repo
$ git clone https://github.com/hashicorp/nomad.git $ cd nomad
- Bootstrap your environment
$ make bootstrap
- (Optionally) Set a higher ulimit, as Nomad creates many file handles during normal operations
$ [ "$(ulimit -n)" -lt 1024 ] && ulimit -n 1024
- Verify you can run tests
$ make test
Running a development build
- Compile a development binary (see the UI README to include the web UI in the binary)
$ make dev # find the built binary at ./bin/nomad
- Start the agent in dev mode
$ sudo bin/nomad agent -dev
- (Optionally) Run Consul to enable service discovery and health checks
- Download Consul
- Start Consul in dev mode
$ consul agent -dev
Compiling Protobufs
If in the course of your development you change a Protobuf file (those ending in .proto), you'll need to recompile the protos.
- Run
make boostrap
to install thebuf
command. - Compile Protobufs
$ make proto
Building the Web UI
See the UI README for instructions.
Create a release binary
To create a release binary:
$ make prerelease
$ make release
$ ls ./pkg
This will generate all the static assets, compile Nomad for multiple
platforms and place the resulting binaries into the ./pkg
directory.
API Compatibility
Only the api/
and plugins/
packages are intended to be imported by other projects. The root Nomad module does not follow semver and is not intended to be imported directly by other projects.
Architecture
The code for Nomad's major components is organized as:
api/
provides a Go client for Nomad's HTTP API.client/
contains Nomad's client agent code.command/
contains Nomad's CLI code.nomad/
contains Nomad's server agent code.ui/
contains Nomad's UI code.website/
contains Nomad's website and documentation.
The high level control flow for many Nomad actions (via the CLI or UI) are:
# Read actions:
Client -> HTTP API -> RPC -> StateStore
# Actions that change state:
Client -> HTTP API -> RPC -> Raft -> FSM -> StateStore
Checklists
When adding new features to Nomad there are often many places to make changes. It is difficult to determine where changes must be made and easy to make mistakes.
The following checklists are meant to be copied and pasted into PRs to give developers and reviewers confidence that the proper changes have been made: