Closes#14729
Expands the Coordination controller used by the CLI client to allow multiple tunnel destinations (agents). Our current client uses just one, but this unifies the logic so that when we add Coder VPN, 1 is just a special case of "many."
chore of #14729
Refactors the `ServerTailnet` to use `tailnet.Controller` so that we reuse logic around reconnection and handling control messages, instead of reimplementing. This unifies our "client" use of the tailscale API across CLI, coderd, and wsproxy.
Fixes a bug where a file produced by `generateVersionFiles` (as used
when uploading a web UI edited template) produced a file where the
`type` field was unset.
This meant the change in #15410 used the unset type value as the content
header when uploading, causing it to always fail.
This adds index.css to the storybook preview file and references to
#storybook-root element in the tailwind config
---------
Co-authored-by: Spike Curtis <spike@coder.com>
Co-authored-by: BrunoQuaresma <bruno_nonato_quaresma@hotmail.com>
This PR:
- Updates the table in `docs/admin/provisioners.md` to include highlight
multi-org changes
- Updates the instructions for the provisionerd helm chart when using
provisioner keys
---------
Co-authored-by: Ben Potter <ben@coder.com>
refactors `tailnetAPIConnector` to use the `Dialer` interface in `tailnet`, introduced lower in this stack of PRs. This will let us use the same Tailnet API handling code across different things that connect to the Tailnet API (CLI client, coderd, workspace proxies, and soon: Coder VPN).
chore re: #14729
Run logs are currently dropped on the floor when workspacetraffic tests fail.
e.g. https://github.com/coder/coder/runs/32640144785
This prints the logs when we get a failure, like
```
run_test.go:341:
Error Trace: /Users/spike/repos/coder/scaletest/workspacetraffic/run_test.go:341
/Users/spike/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.22.8.darwin-arm64/src/runtime/asm_arm64.s:1222
Error: Received unexpected error:
badness:
github.com/coder/coder/v2/scaletest/workspacetraffic.(*Runner).Run
/Users/spike/repos/coder/scaletest/workspacetraffic/run.go:174
Test: TestRun/App
Messages: RUN LOGS:
2024-11-07 13:04:30.274 [debu] config agent_id=00000000-0000-0000-0000-000000000000 reconnecting_pty_id=95bb480f-cd26-4633-8332-328d44ffa997 height=25 width=80 tick_interval=1s bytes_per_tick=1024
2024-11-07 13:04:30.274 [debu] connect to workspace agent agent_id=00000000-0000-0000-0000-000000000000
2024-11-07 13:04:30.274 [info] sending traffic to workspace app agent_id=00000000-0000-0000-0000-000000000000 app=echo
2024-11-07 13:04:30.276 [debu] reading from agent agent_id=00000000-0000-0000-0000-000000000000
2024-11-07 13:04:30.276 [debu] writing to agent agent_id=00000000-0000-0000-0000-000000000000
2024-11-07 13:04:31.526 [debu] done reading from agent agent_id=00000000-0000-0000-0000-000000000000
2024-11-07 13:04:32.276 [debu] done writing to agent agent_id=00000000-0000-0000-0000-000000000000
END RUN LOGS
```
So, hopefully we can diagnose flakes.
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\""
```
Relates to https://github.com/coder/coder/pull/15416
This PR modifies the provisioner helm chart logic:
- Previously, when both provisionerDaemon.keySecretName and provisionerDaemon.pskSecretName
were both set, we would fail to install the chart. This required users to have an obnoxious workaround
in place where setting provisionerDaemon.pskSecretName="" was required in order to use provisioner
keys. We now check for pskSecretName being set to the default value when keySecretName is also specified,
and switch to provisioner key authentication instead of PSK. The previous workaround is still supported.
- We also had omitted to check for provisionerd.Tags being set along with provisionerDaemon.keySecretName.
This would result in a crashlooping provisioner deployment, as setting both of these configuration options is
not allowed. We now fast-fail the Helm deployment if we detect this scenario.
The current description of "Configure your notification preferences.
Icons on the right of each notification indicate delivery method, either
SMTP or Webhook." doesn't really say what this page is for.
I've adjusted the wording, and also changed the tooltip of the delivery
method icon to be more clear.
Signed-off-by: Danny Kopping <danny@coder.com>
Refers to #14984
Currently, password validation is done backend side and is not explicit
enough so it can be painful to create first users.
We'd like to make this validation easier - but also duplicate it
frontend side to make it smoother.
Flows involved :
- First user set password
- New user set password
- Change password
---------
Co-authored-by: BrunoQuaresma <bruno_nonato_quaresma@hotmail.com>
Closes#15292.
Currently, if the frontend never sees a build job enter 'running', it'll
never end up watching the logs. If we start watching the logs earlier
we're able to catch cases where the job goes `pending` -> `failed`, such
as when the build fails immediately.
Filter is applied in original workspace query. We do not need to join
`workspaces` twice. Use build_number instead of `created_at`
for determining the last build.
Refactors the way clients of the Tailnet API (clients of the API, which include both workspace "agents" and "clients") interact with the API. Introduces the idea of abstract "controllers" for each of the RPCs in the API, and implements a Coordination controller by refactoring from `workspacesdk`.
chore re: #14729
Anyone with authz access to a workspace should be able to read timings
information of its builds.
To do this without `AsSystemContext` would do an extra 4 db calls.
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.
Spike Curtis
