Previously in #18635 we delayed the containers API `Init` to avoid producing
errors due to Docker and `@devcontainers/cli` not yet being installed by startup
scripts. This had an adverse effect on the UX via UI responsiveness as the
detection of devcontainers was greatly delayed.
This change splits `Init` into `Init` and `Start` so that we can immediately
after `Init` start serving known devcontainers (defined in Terraform), improving
the UX.
Related #18635
Related #18640
This PR replaces the use of the **container** ID with the
**devcontainer** ID. This is a breaking change. This allows rebuilding a
devcontainer when there is no valid container ID.
Closes https://github.com/coder/internal/issues/732
We now try (up to 5 times) when attempting to create an agent using the
workspace folder as the name.
It is important to note this flow is only ever ran when attempting to
create an agent using the workspace folder as the name. If a deployment
uses terraform or the devcontainer customization, we do not fall back to
this approach.
This PR changes the logic for how we decide on an agent name.
Previously it followed these steps:
1. Use a name from `customizations.coder.name`
2. Use a name from the terraform resource `coder_devcontainer`
3. Use the dev container's friendly name
With this change it now does:
1. Use a name from `customizations.coder.name`
2. Use a name from the terraform resource `coder_devcontainer`
3. Use a name from the workspace folder
4. Use the dev container's friendly name
We now attempt to construct a valid agent name from the workspace
folder. Should we fail to construct a valid agent name from the
workspace folder, we will fall back to the dev container's friendly
name.
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Previously, `CODER_WORKSPACE_AGENT_NAME` would always be passed as the
dev container name.
This is invalid for the following scenarios:
- The dev container is specified in terraform
- The dev container has a name customization
This change now runs `ReadConfig` twice. The first read is to extract a
name (if present), from the `devcontainer.json`. The second read will
then use the name we have stored for the dev container (so this could be
either the customization, terraform resource name, or container name).
Relates to https://github.com/coder/internal/issues/732
This PR supports specifying a name that will be used for the
devcontainer agent in the customizations section of the
devcontainer.json configuration file.
Add apps to the sub agent based on the dev container customization.
The implementation also provides the following env variables for use in
the devcontainer json
- `CODER_WORKSPACE_AGENT_NAME`
- `CODER_WORKSPACE_USER_NAME`
- `CODER_WORKSPACE_NAME`
- `CODER_DEPLOYMENT_URL`
This commit consolidates two container endpoints on the backend and improves the
frontend devcontainer support by showing names and displaying apps as
appropriate.
With this change, the frontend now has knowledge of the subagent and we can also
display things like port forwards.
The frontend was updated to show dev container labels on the border as well as
subagent connection status. The recreation flow was also adjusted a bit to show
placeholder app icons when relevant.
Support for apps was also added, although these are still WIP on the backend.
And the port forwarding utility was added in since the sub agents now provide
the necessary info.
Fixescoder/internal#666
This PR fixes a mistake from the previous PR
https://github.com/coder/coder/pull/18342. Merged configuration results
in the customization being an array not an object.
This PR also moves `displayApps` from being an array to being an object,
like the terraform provider has.
This change introduces a refactor of the devcontainers recreation logic
which is now handled asynchronously rather than being request scoped.
The response was consequently changed from "No Content" to "Accepted" to
reflect this.
A new `Status` field was introduced to the devcontainer struct which
replaces `Running` (bool). This reflects that the devcontainer can now
be in various states (starting, running, stopped or errored).
The status field also protects against multiple concurrent recrations,
as long as they are initiated via the API.
Updates #16424
This change introduces a significant refactor to the agentcontainers API
and enables periodic updates of Docker containers rather than on-demand.
Consequently this change also allows us to move away from using a
locking channel and replace it with a mutex, which simplifies usage.
Additionally a previous oversight was fixed, and testing added, to clear
devcontainer running/dirty status when the container has been removed.
Updates coder/coder#16424
Updates coder/internal#621
There were too many ways to configure the agentcontainers API resulting
in inconsistent behavior or features not being enabled. This refactor
introduces a control flag for enabling or disabling the containers API.
When disabled, all implementations are no-op and explicit endpoint
behaviors are defined. When enabled, concrete implementations are used
by default but can be overridden by passing options.
This change allows listing both predefined and runtime-detected
devcontainers, as well as showing whether or not the devcontainer is
running and which container represents it.
Fixescoder/internal#478
This refactor improves separation of API and containers with minimal
changes to logic.
Highlights:
- Routes are now defined in `agentcontainers` package
- Handler renamed to API
- API lazy init was moved into NewAPI
- Tests that don't need to be internal were made external
