Refactors our use of `slogtest` to instantiate a "standard logger" across most of our tests. This standard logger incorporates https://github.com/coder/slog/pull/217 to also ignore database query canceled errors by default, which are a source of low-severity flakes.
Any test that has set non-default `slogtest.Options` is left alone. In particular, `coderdtest` defaults to ignoring all errors. We might consider revisiting that decision now that we have better tools to target the really common flaky Error logs on shutdown.
- Adds documentation for how to correctly hold --parameter with list(string)
- Adds tests for the aforementioned documented correct finger positions for --parameter list(string)
Adds a `--things` flag to our `multi-select` example prompt command.
```
go run ./cmd/coder exp prompt-example multi-select --things=Code,Bike,Potato=mashed
"Code, Bike, Potato=mashed" are nice choices.
```
Related to #15309
As we already are doing for agent logs - this PR is enabling the logs
rotation for coderd logs.
Currently keeping the same logic than we had for agent - with 5MB as the
file size for rotation.
Whilst the `networking-troubleshooting` docs page already mentions that
a direct connection can be established over a private network, even if
there are no STUN servers, it's worth this is the case at the end of the
ping output.
This also removes a print statement that was dirtying up the diagnostic
output, and corrects the name of the `--disable-direct-connections`
flag.
Fixes a race in TestUpdateValidateRichParameters where the parameter is sent prior to the prompt.
Causes errors like: https://github.com/coder/coder/actions/runs/11681622439/job/32527173007
```
ptytest.go:132: 2024-11-05 10:02:18.819: cmd: "bool_parameter"
ptytest.go:167: 2024-11-05 10:02:18.819: cmd: matched "bool_parameter" = "bool_parameter"
update_test.go:440: 2024-11-05 10:02:18.819: cmd: stdin: "cat\r\n"
ptytest.go:132: 2024-11-05 10:02:18.819: cmd: "> Enter a value (default: \"\"): can't validate build parameter \"bool_parameter\": boolean value can be either \"true\" or \"false\""
ptytest.go:167: 2024-11-05 10:02:18.819: cmd: matched "boolean value can be either" = "\n> Enter a value (default: \"\"): can't validate build parameter \"bool_parameter\": boolean value can be either"
update_test.go:440: 2024-11-05 10:02:18.819: cmd: stdin: "\r\n"
ptytest.go:167: 2024-11-05 10:02:18.819: cmd: matched "Enter a value" = " \"true\" or \"false\"\n> Enter a value"
update_test.go:440: 2024-11-05 10:02:18.819: cmd: stdin: "false\r\n"
ptytest.go:132: 2024-11-05 10:02:18.821: cmd: "> Enter a value (default: \"\"): can't validate build parameter \"bool_parameter\": boolean value can be either \"true\" or \"false\""
```
This PR is the first in a series aimed at closing
[#15109](https://github.com/coder/coder/issues/15109).
### Changes
- **Template Database Creation:**
`dbtestutil.Open` now has the ability to create a template database if
none is provided via `DB_FROM`. The template database’s name is derived
from a hash of the migration files, ensuring that it can be reused
across tests and is automatically updated whenever migrations change.
- **Optimized Database Handling:**
Previously, `dbtestutil.Open` would spin up a new container for each
test when `DB_FROM` was unset. Now, it first checks for an active
PostgreSQL instance on `localhost:5432`. If none is found, it creates a
single container that remains available for subsequent tests,
eliminating repeated container startups.
These changes address the long individual test times (10+ seconds)
reported by some users, likely due to the time Docker took to start and
complete migrations.
Closes https://github.com/coder/coder/issues/15213
This PR enables sending notifications without requiring the auth system
context, instead using a new auth notifier context.
Before db_metrics were all or nothing. Now `InTx` metrics are always recorded, and query metrics are opt in.
Adds instrumentation & logging around serialization failures in the database.
Related to https://github.com/coder/coder/issues/15087
As part of sniffing the workspace tags from an uploaded file, we need to
be able to handle both zip and tar files. Extracting the functions to
a separate `archive` package will be helpful here.
Joins in fields like `username`, `avatar_url`, `organization_name`,
`template_name` to `workspaces` via a **view**.
The view must be maintained moving forward, but this prevents needing to
add RBAC permissions to fetch related workspace fields.
Fixes https://github.com/coder/coder/issues/12721
If a container in docker is started with `--cgroupns=private` (which is
the default behaviour in docker) then `/proc/1/cgroup` has the following
content:
```
0::/
```
If a container in docker is started with `--cgroupns=host` then
`/proc/1/cgroup` has the following content (hash will vary):
```
0::/docker/aa86ac98959eeedeae0ecb6e0c9ddd8ae8b97a9d0fdccccf7ea7a474f4e0bb1f
```
Currently we are determining if a host is containerized by assuming the
second scenario. This means the existing behaviour of sniffing
`/proc/1/cgroup` is not always sufficient for checking if a host is
containerized.
According to [the cgroups(7)
man-page](https://man7.org/linux/man-pages/man7/cgroups.7.html) there
exists a `cgroup.type` file in a nonroot cgroup. This exists in Linux
versions after `4.14`.
> Linux 4.14 added thread mode for cgroups v2.
> With the addition of thread mode, each nonroot cgroup now contains a
new file, cgroup.type
This means we can check for the existence of
`/sys/fs/cgroup/cgroup.type` to see if we are in a container or not.
This PR aims to rename `build-option` to `ephemeral-parameters` based on
#10488 conversation.
`build-option` has been renamed `ephemeral-parameter` and can be used to
define a value for an ephemeral parameter in the template.
`build-options` has been renamed `prompt-ephemeral-parameters` and can
be used to prompt the user to put values for the ephemeral parameters in
the template.
---------
Co-authored-by: Mathias Fredriksson <mafredri@gmail.com>
Co-authored-by: EdwardAngert <17991901+EdwardAngert@users.noreply.github.com>
Co-authored-by: defelmnq <yvincent@coder.com>
This PR is a proposal to improve the situation described in #14750
For some precise commands - we would like to be able to use durations
bigger than hours, minutes..
This PR extends the Duration proposed by Go with :
- `d` - a day or 24hours.
- `y` - a year or 365 days.
I also removed the default value for lifetime and instead fetch the
maxLifetime value from codersdk - so by default if no value set we use
the value defined in the config.
Spike Curtis