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>
As it turns out, prebuilds + devcontainers appear to already work
together. This PR has created a test that simulates a prebuild claim
happening to `agentcontainers.API`, to see how we handle it.
Closes https://github.com/coder/internal/issues/711
When a `devcontainer.json` has been found and it has `.customizations.coder.autoStart = true`, we will now auto start this dev container.
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 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
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
The previous method of refreshing after we change the devcontainer
status introduced an intermediary state where the devcontainer might not
yet have been assigned a container and will flicker as stopped before
going into running.
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.
Listen to feedback that was missed in
https://github.com/coder/coder/pull/18346
- Adds `CODER_WORKSPACE_OWNER_NAME` into the agent environment.
- Logs warnings for when dev container app creation fails.
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.
Danielle Maywood