Partially implements https://github.com/coder/internal/issues/893
This isn't the full implementation of `coder exp tasks create` as
defined in the issue, but it is the minimum required to create a task.
Fixescoder/internal#892Fixescoder/internal#896
Example output:
```
❯ coder exp task list
ID NAME STATUS STATE STATE CHANGED MESSAGE
a7a27450-ca16-4553-a6c5-9d6f04808569 task-hardcore-herschel-bd08 running idle 5h22m3s ago Listed root directory contents, working directory reset
50f92138-f463-4f2b-abad-1816264b065f task-musing-dewdney-f058 running idle 6h3m8s ago Completed arithmetic calculation
```
Note: this commit was partially authored by AI.
- Replaces coderdtest.CreateTemplate/TemplateVersion() with direct dbgen
calls. We do not need a fully functional template for these tests.
- Removes provisioner daemon creation/cleanup. We do not need a running
provisioner daemon here; this functionality is tested elsewhere.
- Simplifies provisioner job creation test helpers.
This reduces the test runtime by over 50%:
Old:
```
time go test -count=100 ./cli -test.run=TestProvisionerJobs
ok github.com/coder/coder/v2/cli 50.149s
```
New:
```
time go test -count=100 ./cli -test.run=TestProvisionerJobs
ok github.com/coder/coder/v2/cli 21.898
```
## Summary
In this pull request we're adding support for additional filtering
options to the `provisioners list` CLI command and the
`/provisionerdaemons` API endpoint.
Resolves: https://github.com/coder/coder/issues/18783
### Changes
#### Added CLI Options
- `--show-offline`: When this option is provided, all provisioner
daemons will be returned. This means that when `--show-offline` is not
provided only `idle` and `busy` provisioner daemons will be returned.
- `--status=<list_of_statuses>`: When this option is provided with a
comma-separated list of valid statuses (`idle`, `busy`, or `offline`)
only provisioner daemons that have these statuses will be returned.
- `--max-age=<duration>`: When this option is provided with a valid
duration value (e.g., `24h`, `30s`) only provisioner daemons with a
`last_seen_at` timestamp within the provided max age will be returned.
#### Query Params
- `?offline=true`: Include offline provisioner daemons in the results.
Offline provisioner daemons will be excluded if `?offline=false` or if
offline is not provided.
- `?status=<list_of_statuses>`: Include provisioner daemons with the
specified statuses.
- `?max_age=<duration>`: Include provisioner daemons with a
`last_seen_at` timestamp within the max age duration.
#### Frontend
- Since offline provisioners will not be returned by default anymore
(`--show-offline` has to be provided to see them), a checkbox was added
to the provisioners list page to allow for offline provisioners to be
displayed
- A revamp of the provisioners page will be done in:
https://github.com/coder/coder/issues/17156, this checkbox change was
just added to maintain currently functionality with the backend updates
Current provisioners page (without checkbox)
<img width="1329" height="574" alt="Screenshot 2025-08-20 at 10 51
00 AM"
src="https://github.com/user-attachments/assets/77b73650-0b62-44f0-a77f-acbe5710809f"
/>
Provisioners page with checkbox (unchecked)
<img width="1314" height="626" alt="Screenshot 2025-08-20 at 10 48
40 AM"
src="https://github.com/user-attachments/assets/7ba164ad-6d3f-417b-bd39-338c0161b145"
/>
Provisioner page with checkbox (checked) and URL updated with query
parameters
<img width="1306" height="597" alt="Screenshot 2025-08-20 at 10 50
14 AM"
src="https://github.com/user-attachments/assets/e78d0986-bbf8-491b-9d56-b682973237a0"
/>
### Show Offline vs Offline Status
To list offline provisioner daemons, users can either:
1. Include the `--show-offline` option
OR
2. Include `offline` in the list of values provided to the `--status`
option
fixes https://github.com/coder/internal/issues/559
This test is looking to see that after calling `coder schedule extend
<workspace> 10h`, the scheduled stop time of the workspace is updated
appropriately (or at least that the information printed to the terminal
indicates that).
By using two `time.Now()` calls for the current time and the expected
time, there was the possibility that the second call just barely crossed
over the hour mark. This is shown in the error message when the test
would flake: `wanted "2025-04-07T22:"; got " 2025-04-07T23:00:00+05:30
\r\n"` (the 00:00 letting us know we just barely crossed the hour).
Using the same time object to construct the expected time should fix the
issue.
Fixes https://github.com/coder/internal/issues/907
We convert `workspacesdk.AgentConn` to an interface and generate a mock
for it. This allows writing `coderd` tests that rely on the agent's HTTP
api to not have to set up an entire tailnet networking stack.
This pull request introduces support for external workspace management, allowing users to register and manage workspaces that are provisioned and managed outside of the Coder.
* coder external-workspaces create - Creates a new external workspace (this command extends coder create)
* Example: coder external-workspaces create ext-workspace --template=externally-managed-workspace -y
* Checks if template has coder_external_agent resource before creating a workspace
* coder external-workspaces list - Lists all external workspaces
* coder external-workspaces agent-instructions <workspace name> <agent name> - Retrieves agent connection instruction
* Example: coder external-workspaces agent-instructions ext-workspace main --output=json
This pull request introduces support for external workspace management, allowing users to register and manage workspaces that are provisioned and managed outside of the Coder.
Depends on: https://github.com/coder/terraform-provider-coder/pull/424
* GET /api/v2/init-script - Gets the agent initialization script
* By default, it returns a script for Linux (amd64), but with query parameters (os and arch) you can get the init script for different platforms
* GET /api/v2/workspaces/{workspace}/external-agent/{agent}/credentials - Gets credentials for an external agent **(enterprise)**
* Updated queries to filter workspaces/templates by the has_external_agent field
## Description
This PR adds CLI-side validation to prevent the use of the `coder
schedule` command (including both `start` and `stop` subcommands) on
prebuilt workspaces.
Prebuilt workspaces are scheduled independently by the reconciliation
loop, based on template and preset-level configuration. They do not
participate in the regular user workspace lifecycle, and cannot be
configured via the `coder schedule` CLI command. This change ensures
that attempting to configure scheduling on a prebuilt workspace results
in a clear CLI error.
## Changes
- `coder schedule start` — now returns an error if the target workspace
is a prebuild
- `coder schedule stop` — now returns an error if the target workspace
is a prebuild
Related with:
* Issue: https://github.com/coder/coder/issues/18898
* **Depends on PR**: https://github.com/coder/coder/pull/19252
Breaking change: Field types in `codersdk.UpdateTemplateMeta` for
`Icon`, `Description`, and `DisplayName` moved to `*string`
## Summary
In this pull request we're updating the `UpdateTemplateMeta` struct to
allow `DisplayName`, `Description`, and `Icon` to be set as empty `""`
or default to the value from the template if not provided in an update
call.
Fixes https://github.com/coder/coder/issues/19036
### The bug
The reported bug occurred when clients were attempting to update a
metadata field in a template via an edit call. When the request was
decoded into an `UpdateTemplateMeta` struct the default values for
fields in the struct were used to update the template even if they
weren't provided. This led to fields like `Icon` being set to `""` (the
default value).
### Changes
To allow for specific fields to be set to `""` these fields were updated
to be `*string` as opposed to `string`. This allows for clients to set
these fields as `""` in an update request or they will default to the
template value if they are not provided in the update request (will be
`nil`).
Added tests to confirm empty and nil values and updated other tests that
use these fields.
PProf labels segment the code into groups for determing the source of
cpu/memory profiles. Since the web server and background jobs share a
lot of the same code (eg wsbuilder), it helps to know if the load is
user induced, or background job based.
We disable the logic that allows autostarting discovered devcontainers
by default. We want this behavior to be opt-in rather than opt-out.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
relates to #778
Somehow in `TestWorkspaceAgent` the agent with the test instance identifier is not being added to the database, or is getting deleted.
I'm adding some additional logging to `dbfake` and setting the affected tests to dump postgres on error, to see if we can get to the bottom of the issue.
This PR sets a constraint of 1MB on the provisioner job logs written to
the database. This is consistent with the constraint we place on
workspace agent logs:
https://github.com/coder/coder/blob/4ac6be6d835dc36c242e35a26b584b784040bf28/coderd/database/dump.sql#L2030
It also adds a message printed to the front end about the provisioner
log overflow, and updates the message printed to the front end when
workspace startup logs exceed the max, as it was causing some customers
to think their startup script had failed to run.
Continues to address https://github.com/coder/coder-desktop-macos/issues/201
Identical to the windows command, except we don't write to stdio. We're retaining the system we have for logging on macOS, where we push logs over the tunnel and use the OS logger.
I've tested that a build with this command works end-to-end with my new version of Coder Desktop macOS.
Also brings in the soft net isolation changes from `main` of coder/tailscale.
## Description
This PR improves the `coder templates presets` and `coder create` CLI
commands to include preset descriptions.
## Changes
* Added a `description` column to the `coder templates presets list` CLI
command.
* Fixed the `-o json` output for `coder templates presets list` to
correctly include and format data.
* Updated the `coder create` CLI command to display the preset's
description in the selection menu.
Follow-up from:
* https://github.com/coder/coder/pull/18910
* https://github.com/coder/coder/pull/18912
* https://github.com/coder/coder/pull/18977
## Description
This PR adds support for `description` and `icon` fields to
`template_version_presets`. These fields will allow displaying richer
information for presets in the UI, improving the user experience when
creating a workspace.
Both fields are optional, non-nullable, and default to empty strings.
## Changes
* Database migration with the addition of `description VARCHAR(128)` and
`icon VARCHAR(256)` columns to the `template_version_presets` table.
* Updated the `CreateWorkspacePageView` in the UI
Note: UI changes will be addressed in a separate PR
## Description
This PR introduces a `--preset` flag for the `create` command to allow
users to apply a predefined preset to their workspace build.
## Changes
- The `--preset` flag on the `create` command integrates with the
parameter resolution logic and takes precedence over other sources
(e.g., CLI/env vars, last build, etc.).
- Added internal logic to ensure that preset parameters override
parameters values during resolution.
- Updated tests and added new ones to cover these flows.
## Implementation logic
* If a template has presets and includes a default, the CLI will
automatically use the default when `--preset` is not specified.
* If a template has presets but no default, the CLI will prompt the user
to select one when `--preset` is not specified.
* If a template does not have presets, the CLI will not prompt the user
for a preset.
* If the user specifies a preset using the `--preset` flag, that preset
will be used.
* If the user passes `--preset None`, no preset will be applied.
This logic aligns with the behavior in the UI for consistency.
```
> coder create --help
USAGE:
coder create [flags] [workspace]
Create a workspace
- Create a workspace for another user (if you have permission):
$ coder create <username>/<workspace_name>
OPTIONS:
(...)
--preset string, $CODER_PRESET_NAME
Specify the name of a template version preset. Use 'none' to explicitly indicate that no preset should be used.
(...)
-y, --yes bool
Bypass prompts.
```
## Breaking change
**Note:** This is a breaking change to the create CLI command. If a
template includes presets and the user does not provide a `--preset`
flag, the CLI will now prompt the user to select one. This behavior may
break non-interactive scripts or automated workflows.
Relates to PR: https://github.com/coder/coder/pull/18910 - please
consider both PRs together as they’re part of the same workflow
Relates to issue: https://github.com/coder/coder/issues/16594
## Description
This PR introduces a new `list presets` command to display the presets
associated with a given template.
By default, it displays the presets for the template's active version,
unless a `--template-version` flag is provided.
## Changes
* Added a new `list presets` command under `coder templates presets` to
display presets associated with a template.
* By default, the command lists presets from the template’s active
version.
* Users can override the default behavior by providing the
`--template-version` flag to target a specific version.
```
> coder templates versions presets list --help
USAGE:
coder templates presets list [flags] <template>
List all presets of the specified template. Defaults to the active template version.
OPTIONS:
-O, --org string, $CODER_ORGANIZATION
Select which organization (uuid or name) to use.
-c, --column [name|parameters|default|desired prebuild instances] (default: name,parameters,default,desired prebuild instances)
Columns to display in table output.
-o, --output table|json (default: table)
Output format.
--template-version string
Specify a template version to list presets for. Defaults to the active version.
```
Related PR: https://github.com/coder/coder/pull/18912 - please consider
both PRs together as they’re part of the same workflow
Relates to issue: https://github.com/coder/coder/issues/16594
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added CLI commands to manage and list presets for specific template
versions, supporting tabular and JSON output.
* Introduced a new CLI subcommand group for template version presets,
including detailed help and documentation.
* Added support for displaying and managing the desired number of
prebuild instances for presets in CLI, API, and UI.
* **Documentation**
* Updated and expanded CLI and API documentation to describe new
commands, options, and the desired prebuild instances field in presets.
* Added new help output and reference files for template version presets
commands.
* **Bug Fixes**
* Ensured correct handling and display of the desired prebuild instances
property for presets across CLI, API, and UI.
* **Tests**
* Introduced end-to-end tests for listing template version presets,
covering scenarios with and without presets.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Relates to https://github.com/coder/internal/issues/711
This PR implements a project discovery mechanism that searches for any
dev container projects and makes them visible in the UI so that they can
be started. To make the wording on the site more clear, "Rebuild" has
been changed to "Start" when there is no container associated with a
known dev container configuration. I've also made it so that site will
show the dev container config path when there is no other name
available.
### Design decisions
Just want to ensure my explanation for a few design decisions are noted
down:
- We only search for dev container configurations inside git
repositories
- We only search for these git repositories if they're at the top level
or a direct child of the agent directory.
This limited approach is to reduce the amount of files we ultimately
walk when trying to find these projects. It makes sense to limit it to
only the agent directory, although I'm open to expanding how deep we
search.
This PR introduces new build reason values to identify what type of
connection triggered a workspace build, helping to troubleshoot
workspace-related issues.
## Database Migration
Added migration 000349_extend_workspace_build_reason.up.sql that extends
the build_reason enum with new values:
```
dashboard, cli, ssh_connection, vscode_connection, jetbrains_connection
```
## Implementation
The build reason is specified through the API when creating new
workspace builds:
- Dashboard: Automatically sets reason to `dashboard` when users start
workspaces via the web interface
- CLI `start` command: Sets reason to `cli` when workspaces are started
via the command line
- CLI `ssh` command: Sets reason to ssh_connection when workspaces are
started due to SSH connections
- VS Code connections: Will be set to `vscode_connection` by the VS Code
extension through CLI hidden flag
(https://github.com/coder/vscode-coder/pull/550)
- JetBrains connections: Will be set to `jetbrains_connection` by the
Jetbrains Toolbox
(https://github.com/coder/coder-jetbrains-toolbox/pull/150) and
Jetbrains Gateway extension
(https://github.com/coder/jetbrains-coder/pull/561)
## UI Changes:
* Tooltip with reason in Build history
<img width="309" height="457" alt="image"
src="https://github.com/user-attachments/assets/bde8440b-bf3b-49a1-a244-ed7e8eb9763c"
/>
* Reason in Audit Logs Row tooltip
<img width="906" height="237" alt="image"
src="https://github.com/user-attachments/assets/ebbb62c7-cf07-4398-afbf-323c83fb6426"
/>
<img width="909" height="188" alt="image"
src="https://github.com/user-attachments/assets/1ddbab07-44bf-4dee-8867-b4e2cd56ae96"
/>
- Adds a query for counting managed agent workspace builds between two
timestamps
- The "Actual" field in the feature entitlement for managed agents is
now populated with the value read from the database
- The wsbuilder package now validates AI agent usage against the limit
when a license is installed
Closescoder/internal#777
## Description
This PR updates the UI to avoid rendering workspace schedule settings
(autostop, autostart, etc.) for prebuilt workspaces. Instead, it
displays an informational message with a link to the relevant
documentation.
## Changes
* Introduce `IsPrebuild` parameter to `convertWorkspace` to indicate
whether the workspace is a prebuild.
* Prevent the Workspace Schedule settings form from rendering in the UI
for prebuilt workspaces.
* Display an info alert with a link to documentation when viewing a
prebuilt workspace.
<img width="2980" height="864" alt="Screenshot 2025-07-10 at 13 16 13"
src="https://github.com/user-attachments/assets/5f831c21-50bb-4e05-beea-dbeb930ddff8"
/>
Relates with: https://github.com/coder/coder/pull/18762
---------
Co-authored-by: BrunoQuaresma <bruno_nonato_quaresma@hotmail.com>
## Description
This PR fixes a flaky test in
`TestDelete/Prebuilt_workspace_delete_permissions`:
https://github.com/coder/internal/issues/764
Previously, all subtests used the same context created at the top level.
Since the subtests run in parallel, they could run for too long and
cause the shared context to expire. This sometimes led to context
deadline exceeded errors, especially during the `testutil.Eventually`
check for running prebuilt workspaces.
The fix is to create a fresh context per subtest, ensuring they are
isolated and not prematurely cancelled due to other subtests' durations.
This change allows a devcontainer to be opened via the agent syntax,
`coder open vscode <workspace>.<agent>` and removes the `--container`
option to simplify the subcommand. Accessing the subagent will behave
similarly to how the `--container` option behaved.
Fixescoder/internal#748
Closes#17791
This PR adds ability to cancel workspace builds that are in "pending"
status.
Breaking changes:
- CancelWorkspaceBuild method in codersdk now accepts an optional
request parameter
API:
- Added `expect_status` query parameter to the cancel workspace build
endpoint
- This parameter ensures the job hasn't changed state before canceling
- API returns `412 Precondition Failed` if the job is not in the
expected status
- Valid values: `running` or `pending`
- Wrapped the entire cancel method in a database transaction
UI:
- Added confirmation dialog to the `Cancel` button, since it's a
destructive operation
- Enabled cancel action for pending workspaces (`expect_status=pending`
is sent if workspace is in pending status)
---------
Co-authored-by: Dean Sheather <dean@deansheather.com>
This change adds a new `docker-devcontainer` template which allows you
to provision a workspace running in Docker, that also creates workspaces
via Docker running inside (DinD).
- **chore(examples/templates): rename `docker-devcontainer` to
`docker-envbuilder`**
- **feat(examples/templates): add `docker-devcontainer` example
template**
We were discarding all "working" updates from the screen watcher because
we cannot tell the difference between the agent or user changing the
screen, but it makes sense to accept it as the very first update,
because the agent could be working but neglected to report that fact, so
you would never get an initial "working" update (it would just
eventually go straight to "idle").
Also messages can start at zero, so I made a fix for that as well,
although the first message will be from the LLM and we ignore
those anyway, so this probably has no actual effect, but seems more
technically correct.
And it seems I forgot to actually update the last message ID, which
also does not actually matter for user messages (since I think the
SSE endpoint will not re-emit a user message it has already emitted),
but seems more technically correct to check.
Lastly, if we have the screen watcher, ignore the agent's self-reported
state and always use "working" since it is unreliable. The idle state will
eventually be caught by the watcher.
Danielle Maywood