* [no ci] use json for grouping packages for testing
* [no ci] able to get packages in group
* [no ci] able to run groups of tests
* [no ci] more
* [no ci] try disable circle unit tests
* ci: use actions/checkout@v3
* ci: rename to quick
* ci: need make dev in mods cache step
* ci: make compile step depend on checks step
* ci: bump consul and vault versions
* ci: need make dev for group tests
* ci: update ci unit testing docs
* docs: spell plumbing correctly
Co-authored-by: Tim Gross <tgross@hashicorp.com>
Co-authored-by: Tim Gross <tgross@hashicorp.com>
When community members comment on long-closed issues, there's a number of
failure modes that make for a bad experience for them:
* Their comments are often missed entirely because notification settings make it
impractical for most developers to read comments on inactive issues.
* In our experience, the problem is only rarely a regression; because failures
are complex, totally different code paths can result in symptoms that initially
appear to be the same but turn out to be completely different under close
examination. This is particularly the case for issues fixed in very old
versions (sometimes 2 or more years old).
The Terraform core team uses a bot that locks issues after only 30 days. But
because we typically close issues automatically on PR merge but don't have
rolling releases, it'd frequently happen that unrelease fixes will have locked
comments, which isn't a good experience either. I've looked through the pace of
releases since Nomad 0.9.0 and the longest window between releases was 3
months. Set the window for the lock bot to 120 days to give us plenty of
breathing room so it doesn't feel like we're shutting down discussion
prematurely.
The `hc-install` tool we're using needed a patch for a specific bug, but that's
since been merged. We definitely want to switch to using a standard release from
that project once one is shipped with the CLI, but pinning to HEAD should keep
us for now.
These flags were not being used because GNUmakefile overwrites them with
another value. We also don't want to set `-s -w` since they remove
information that is important for production debug.
In other projects this variable is used to override the default `-dev`
prerelease that is set even if `VersionPrerelease` is empty, but in
Nomad this check is never actually done because this conditional in
`version/version.go` is always false:
```go
func GetVersion() *VersionInfo {
// ...
rel := VersionPrerelease
// ...
if GitDescribe == "" && rel == "" && VersionPrerelease != "" {
rel = "dev"
}
// ...
}
```
This seems like some leftover from a previous release process, but I
decided the leave the code as is.
The website build code has been moved out to another repository, so
what's remaining here is local development tooling. Assign these PRs to
the web platform team, but also cut down on the noise we're sending
their way.
This PR update to Go 1.18.2. Also update the versions of hclfmt
and go-hclogfmt which includes newer dependencies necessary for dealing
with go1.18.
The hcl v2 branch is now 'nomad-v2.9.1+tweaks2', to include a fix for
newer macOS versions: 8927e75e82
Remove the step to automatically backport `backport/website` PRs to the
latest release. This will be done manually by adding the proper tags.
Also use squash backports to match the pattern we use for `main`.
During the release there are several files that need to be modified:
- .release/ci.hcl: the notification channel needs to be updated to a
channel with greater team visibility during the release.
- version/version.go: the Version and VersionPrerelease variables
need to be set so they match the release version.
After the release these files need to be reverted.
For GA releases the following additional changes also need to happen:
- version/version.go: the Version variable needs to be bumped to the
next version number.
- GNUMakefile: the LAST_RELEASE variable needs to be set to the
version that was just released.
Since the release process will commit file changes to the branch being
used for the release, it should _never_ run on main, so the first step
is now to protect against that.
It also adds a validation to make the user input version is correct.
After looking at the different release options and steps I noticed that
automatic CHANGELOG generation is actually the exception, so it would be
better to have the default to be false.
* Sample percy test added
* Node engine up to 14.x for UI prep
* Force ui test rerun
* Updated config.yml
* Node v upgraded to 14 for docker image
* Expect length in test
* Running ember tests under percy exec
* Percy exec format
* Percy cli added
* Noop to rerun tests with updated percy_token
* Evals full list and details open snapshots
* Pretty legit use of assert so disable the warning
* Jobs list tests
* Snapshots for top-level clients, servers, ACL, topology, and storage lists
* Expect caveat for Topology test
* Stabilizing tests with faker seeded to 1
* Seed-stabilizing any tests with percySnapshots
* Faker import
* Drop unused param
* Assets and test audit using an older node version
* New strategy: avoid seeding, just use percyCSS to hide certain things
This PR adds support for the raw_exec driver on systems with only cgroups v2.
The raw exec driver is able to use cgroups to manage processes. This happens
only on Linux, when exec_driver is enabled, and the no_cgroups option is not
set. The driver uses the freezer controller to freeze processes of a task,
issue a sigkill, then unfreeze. Previously the implementation assumed cgroups
v1, and now it also supports cgroups v2.
There is a bit of refactoring in this PR, but the fundamental design remains
the same.
Closes#12351#12348
test_checks.sh was removed in 2019 and now just breaks if VERBOSE is
set when running tests via make targets
in GHA, use verbose mode to display what tests are running
This PR introduces support for using Nomad on systems with cgroups v2 [1]
enabled as the cgroups controller mounted on /sys/fs/cgroups. Newer Linux
distros like Ubuntu 21.10 are shipping with cgroups v2 only, causing problems
for Nomad users.
Nomad mostly "just works" with cgroups v2 due to the indirection via libcontainer,
but not so for managing cpuset cgroups. Before, Nomad has been making use of
a feature in v1 where a PID could be a member of more than one cgroup. In v2
this is no longer possible, and so the logic around computing cpuset values
must be modified. When Nomad detects v2, it manages cpuset values in-process,
rather than making use of cgroup heirarchy inheritence via shared/reserved
parents.
Nomad will only activate the v2 logic when it detects cgroups2 is mounted at
/sys/fs/cgroups. This means on systems running in hybrid mode with cgroups2
mounted at /sys/fs/cgroups/unified (as is typical) Nomad will continue to
use the v1 logic, and should operate as before. Systems that do not support
cgroups v2 are also not affected.
When v2 is activated, Nomad will create a parent called nomad.slice (unless
otherwise configured in Client conifg), and create cgroups for tasks using
naming convention <allocID>-<task>.scope. These follow the naming convention
set by systemd and also used by Docker when cgroups v2 is detected.
Client nodes now export a new fingerprint attribute, unique.cgroups.version
which will be set to 'v1' or 'v2' to indicate the cgroups regime in use by
Nomad.
The new cpuset management strategy fixes#11705, where docker tasks that
spawned processes on startup would "leak". In cgroups v2, the PIDs are
started in the cgroup they will always live in, and thus the cause of
the leak is eliminated.
[1] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.htmlCloses#11289Fixes#11705#11773#11933
Luiz Aoqui