mirror of
https://github.com/coder/coder.git
synced 2026-09-24 15:04:27 +08:00
refactor(docs): convert absolute coder/coder blob/tree/main links to relative (DOCS-351) (#26341)
Closes [DOCS-351](https://linear.app/codercom/issue/DOCS-351). > [!WARNING] > **DO NOT MERGE** until [DOCS-349](https://linear.app/codercom/issue/DOCS-349) ([coder.com#877](https://github.com/coder/coder.com/pull/877)) has shipped to production and baked for at least one Vercel cycle. > > Without DOCS-349, the relative links in this PR resolve to broken docs-route URLs (`/docs/helm/coder/values.yaml` -> 404) instead of GitHub URLs tagged with the displayed docs version. DOCS-349 fixes the rewriter to classify these as GitHub blob/tree URLs with the page's resolved ref. ## TL;DR Converts 121 absolute `https://github.com/coder/coder/(blob|tree)/main/<path>` links across 39 docs markdown files to relative paths. After this lands AND DOCS-349 deploys, every one of these links will follow the displayed docs version (mainline tag on bare URLs, explicit tag on `/@vX.Y.Z/`, `main` on `/@main/`) instead of always pointing to `main`. ## Why Today a reader on `/docs/@v2.30.0/install/docker` follows a `compose.yaml` link and arrives at `main`'s `compose.yaml`, which doesn't necessarily match what the docs page describes. Helm values, Terraform templates, and source-code references in particular drift across versions. The fix is to let the coder.com rewriter substitute the page's resolved ref into the URL; that only works on relative links. ## Example payoff (post-DOCS-349) | URL | Today (absolute, always `main`) | After (relative + rewriter) | |---|---|---| | `/docs/install/docker` | `https://github.com/coder/coder/blob/main/compose.yaml` | `https://github.com/coder/coder/blob/v2.34.1/compose.yaml` (today's mainline) | | `/docs/@v2.30.0/install/docker` | same as above | `https://github.com/coder/coder/blob/v2.30.0/compose.yaml` | | `/docs/@main/install/docker` | same as above | `https://github.com/coder/coder/blob/main/compose.yaml` | ## Scope - **121 conversions** across **39 files**. - Verb breakdown: `tree/main` (directories) and `blob/main` (files), both flipped to relative paths. - Line anchors (`#L23-L24`) and query strings preserved verbatim. - Conversion is mechanical: relative path computed from the doc file's directory to the target via `os.path.relpath`. Any path starting at the same directory or below gets a `./` prefix; otherwise `../` chains. ## Rebased on main The branch was rebased onto `main` after the DOCS-350 hotfix ([#26339](https://github.com/coder/coder/pull/26339)) merged. The hotfix repointed 3 `docs-backend-contrib-guide` refs in `backend.md` to `main`, which then needed the same `main` -> relative conversion this PR is doing for the other 121 links. The conflict was resolved by reapplying the mechanical conversion to `backend.md` after taking the hotfix's content. Net result: those 3 links land here as relative, same as everything else. New HEAD `3f501cb622`. ## Inline fix folded in: dead `nix` link - `docs/about/contributing/CONTRIBUTING.md:7` -> `../../../nix` The original absolute URL `https://github.com/coder/coder/tree/main/nix` already returned 404 today. Repointed to `flake.nix` (modern Nix entrypoint, what the prose "Nix environment" semantically refers to). Closes [DOCS-357](https://linear.app/codercom/issue/DOCS-357) here since the `check-docs` Linkspector job surfaced it during rebase; cheaper to fix inline than in a separate single-line PR. ## Out of scope (filed separately) - [DOCS-350](https://linear.app/codercom/issue/DOCS-350): 3 dead `docs-backend-contrib-guide` branch refs in `backend.md` ([#26339](https://github.com/coder/coder/pull/26339), merged). - [DOCS-352](https://linear.app/codercom/issue/DOCS-352): 10 SHA-pinned `(blob|tree)/<sha>` links pending intent review. - [DOCS-355](https://linear.app/codercom/issue/DOCS-355): code-server analog (4 absolute `(blob|tree)/main` links in `coder/code-server`). - [DOCS-356](https://linear.app/codercom/issue/DOCS-356): 2 upstream content bugs in `coder/code-server/docs/CONTRIBUTING.md` (independent of this PR). ## Not triggering `/coder-agents-review` Docs-only edit; per `AGENTS.md` the bot review is reserved for product/CI changes. ## Pre-mortem | Concern | Mitigation | |---|---| | Merging before DOCS-349 deploys regresses ~120 currently-working links into 404s on coder.com | Clear DO-NOT-MERGE banner; tracked as blocker in Linear. | | Relative path computed incorrectly (off-by-one `..`) | Verified all 114 newly-relative non-md/non-image paths resolve to existing files in the repo (only exception is the pre-existing dead `nix` link above). | | Line anchors stripped during conversion | Preserved by the substitution regex; verified `#L<n>-L<m>` cases in `airgap.md` and `speed-up-templates.md`. | | Future code reorgs change file locations | Relative links will start pointing to nothing. Same failure mode as absolute links pointing to renamed files; can be caught with a future link-checker job. | ## Validation ``` $ grep -rE 'github\.com/coder/coder/(blob|tree)/main' docs --include="*.md" | wc -l 0 $ git diff --stat origin/main | tail -1 39 files changed, 118 insertions(+), 118 deletions(-) ``` 114 newly-relative paths verified to resolve to existing repo files (Python `os.path.exists` check on each computed target). <details> <summary>Decision log + planning context</summary> **Why relative over `(blob|tree)/{{currentDocsVersion}}/...` templating**: relative paths require zero markdown-system support and zero upstream churn beyond this one PR. Templating would require a preprocessor on `coder.com` side AND a convention upstream authors have to remember; relative paths just work in a plain editor and `github.com`'s own renderer too. **Why `./` prefix on same-directory targets**: makes the conversion grep-able later (`grep -E '\((\.\./|\./)'`). **Why preserve `#L<n>-L<m>` anchors verbatim**: the anchor is meaningful to the linked file's content, not to the URL form; keeping it as-is preserves authorial intent. If the file later changes such that the line range drifts, that's a different problem the SHA-pin audit ([DOCS-352](https://linear.app/codercom/issue/DOCS-352)) will surface. </details> --- *Generated by Coder Agents on @nickvigilante's behalf.* ## Drive-by external link fix folded in `docs/about/contributing/CONTRIBUTING.md:296` cited `https://reflectoring.io/meaningful-commit-messages/` which is returning HTTP 503 (the host appears to be down site-wide right now). `check-docs` Linkspector flagged it after the rebase. Replaced with `https://cbea.ms/git-commit/` (Chris Beams' canonical "If applied, this commit will..." article, confirmed 200), which is the original source of the rule the prose recites anyway.
This commit is contained in:
+1
-1
@@ -130,7 +130,7 @@ For workspaces, this means admins can:
|
||||
## Pricing
|
||||
|
||||
Coder is free and open source under the
|
||||
[GNU Affero General Public License v3.0](https://github.com/coder/coder/blob/main/LICENSE).
|
||||
[GNU Affero General Public License v3.0](../LICENSE).
|
||||
All developer productivity features are included in the open source version.
|
||||
A [Premium license](https://coder.com/pricing#compare-plans) is available for
|
||||
enhanced support and custom deployments.
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
<div class="tabs">
|
||||
|
||||
To get started with Coder, the easiest way to set up the required environment is to use the provided [Nix environment](https://github.com/coder/coder/tree/main/nix).
|
||||
To get started with Coder, the easiest way to set up the required environment is to use the provided [Nix environment](../../../flake.nix).
|
||||
Learn more [how Nix works](https://nixos.org/guides/how-nix-works).
|
||||
|
||||
### Nix
|
||||
@@ -56,7 +56,7 @@ Learn more [how Nix works](https://nixos.org/guides/how-nix-works).
|
||||
|
||||
### Without Nix
|
||||
|
||||
If you're not using the Nix environment, you can launch a local [DevContainer](https://github.com/coder/coder/tree/main/.devcontainer) to get a fully configured development environment.
|
||||
If you're not using the Nix environment, you can launch a local [DevContainer](../../../.devcontainer) to get a fully configured development environment.
|
||||
|
||||
DevContainers are supported in tools like **VS Code** and **GitHub Codespaces**, and come preloaded with all required dependencies: Docker, Go, Node.js with `pnpm`, `mise`, and `make`.
|
||||
|
||||
@@ -114,7 +114,7 @@ the Makefile trigger the full targets as before.
|
||||
./scripts/coder-dev.sh list
|
||||
```
|
||||
|
||||
This should return an empty list of workspaces. If you encounter an error, review the output from the [develop.sh](https://github.com/coder/coder/blob/main/scripts/develop.sh) script for issues.
|
||||
This should return an empty list of workspaces. If you encounter an error, review the output from the [develop.sh](../../../scripts/develop.sh) script for issues.
|
||||
|
||||
> [!NOTE]
|
||||
> `coder-dev.sh` is a helper script that behaves like the regular coder CLI, but uses the binary built from your local source and shares the same configuration directory set up by `develop.sh`. This ensures your local changes are reflected when testing.
|
||||
@@ -212,7 +212,7 @@ be applied selectively or to discourage anyone from contributing.
|
||||
## Releases
|
||||
|
||||
Coder releases are managed entirely through the
|
||||
[`release.yaml`](https://github.com/coder/coder/blob/main/.github/workflows/release.yaml)
|
||||
[`release.yaml`](../../../.github/workflows/release.yaml)
|
||||
GitHub Actions workflow, triggered manually via "Run workflow" in the Actions
|
||||
tab. Release notes are automatically generated from commit titles and PR
|
||||
metadata.
|
||||
@@ -293,7 +293,7 @@ changes are within that directory. If changes span multiple top-level
|
||||
directories, omit the scope.
|
||||
|
||||
A good rule of thumb for writing good commit messages is to recite:
|
||||
[If applied, this commit will ...](https://reflectoring.io/meaningful-commit-messages/).
|
||||
[If applied, this commit will ...](https://cbea.ms/git-commit/).
|
||||
|
||||
**Note:** We lint PR titles to ensure they follow the Conventional Commits
|
||||
specification, however, it's still possible to merge PRs on GitHub with a badly
|
||||
@@ -304,7 +304,7 @@ to use the original commit title instead of the PR title.
|
||||
|
||||
When a merged PR on `main` should also ship in older releases, add the
|
||||
`backport` label to the PR. The
|
||||
[backport workflow](https://github.com/coder/coder/blob/main/.github/workflows/backport.yaml)
|
||||
[backport workflow](../../../.github/workflows/backport.yaml)
|
||||
will automatically detect the latest three `release/*` branches,
|
||||
cherry-pick the merge commit onto each one, and open PRs for
|
||||
review.
|
||||
|
||||
@@ -49,78 +49,78 @@ Coder's backend is built using a collection of robust, modern Go libraries and i
|
||||
|
||||
The Coder backend is organized into multiple packages and directories, each with a specific purpose. Here's a high-level overview of the most important ones:
|
||||
|
||||
* [agent](https://github.com/coder/coder/tree/main/agent): core logic of a workspace agent, supports DevContainers, remote SSH, startup/shutdown script execution. Protobuf definitions for DRPC communication with `coderd` are kept in [proto](https://github.com/coder/coder/tree/main/agent/proto).
|
||||
* [cli](https://github.com/coder/coder/tree/main/cli): CLI interface for `coder` command built on [coder/serpent](https://github.com/coder/serpent). Input controls are defined in [cliui](https://github.com/coder/coder/tree/main/cli/cliui), and [testdata](https://github.com/coder/coder/tree/main/cli/testdata) contains golden files for common CLI calls
|
||||
* [cmd](https://github.com/coder/coder/tree/main/cmd): entry points for CLI and services, including `coderd`
|
||||
* [coderd](https://github.com/coder/coder/tree/main/coderd): the main API server implementation with [chi](https://github.com/go-chi/chi) endpoints
|
||||
* [audit](https://github.com/coder/coder/tree/main/coderd/audit): audit log logic, defines target resources, actions and extra fields
|
||||
* [autobuild](https://github.com/coder/coder/tree/main/coderd/autobuild): core logic of the workspace autobuild executor, periodically evaluates workspaces for next transition actions
|
||||
* [httpmw](https://github.com/coder/coder/tree/main/coderd/httpmw): HTTP middlewares mainly used to extract parameters from HTTP requests (e.g. current user, template, workspace, OAuth2 account, etc.) and storing them in the request context
|
||||
* [prebuilds](https://github.com/coder/coder/tree/main/coderd/prebuilds): common interfaces for prebuild workspaces, feature implementation is in [enterprise/prebuilds](https://github.com/coder/coder/tree/main/enterprise/coderd/prebuilds)
|
||||
* [provisionerdserver](https://github.com/coder/coder/tree/main/coderd/provisionerdserver): DRPC server for [provisionerd](https://github.com/coder/coder/tree/main/provisionerd) instances, used to validate and extract Terraform data and resources, and store them in the database.
|
||||
* [rbac](https://github.com/coder/coder/tree/main/coderd/rbac): RBAC engine for `coderd`, including authz layer, role definitions and custom roles. Built on top of [Open Policy Agent](https://github.com/open-policy-agent/opa) and Rego policies.
|
||||
* [telemetry](https://github.com/coder/coder/tree/main/coderd/telemetry): records a snapshot with various workspace data for telemetry purposes. Once recorded the reporter sends it to the configured telemetry endpoint.
|
||||
* [tracing](https://github.com/coder/coder/tree/main/coderd/tracing): extends telemetry with tracing data consistent with [OpenTelemetry specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md)
|
||||
* [workspaceapps](https://github.com/coder/coder/tree/main/coderd/workspaceapps): core logic of a secure proxy to expose workspace apps deployed in a workspace
|
||||
* [wsbuilder](https://github.com/coder/coder/tree/main/coderd/wsbuilder): wrapper for business logic of creating a workspace build. It encapsulates all database operations required to insert a build record in a transaction.
|
||||
* [database](https://github.com/coder/coder/tree/main/coderd/database): schema migrations, query logic, in-memory database, etc.
|
||||
* [db2sdk](https://github.com/coder/coder/tree/main/coderd/database/db2sdk): translation between database structures and [codersdk](https://github.com/coder/coder/tree/main/codersdk) objects used by coderd API.
|
||||
* [dbauthz](https://github.com/coder/coder/tree/main/coderd/database/dbauthz): AuthZ wrappers for database queries, ideally, every query should verify first if the accessor is eligible to see the query results.
|
||||
* [dbfake](https://github.com/coder/coder/tree/main/coderd/database/dbfake): helper functions to quickly prepare the initial database state for testing purposes (e.g. create N healthy workspaces and templates), operates on higher level than [dbgen](https://github.com/coder/coder/tree/main/coderd/database/dbgen)
|
||||
* [dbgen](https://github.com/coder/coder/tree/main/coderd/database/dbgen): helper functions to insert raw records to the database store, used for testing purposes
|
||||
* [dbmock](https://github.com/coder/coder/tree/main/coderd/database/dbmock): a store wrapper for database queries, useful to verify if the function has been called, used for testing purposes
|
||||
* [dbpurge](https://github.com/coder/coder/tree/main/coderd/database/dbpurge): simple wrapper for periodic database cleanup operations
|
||||
* [migrations](https://github.com/coder/coder/tree/main/coderd/database/migrations): an ordered list of up/down database migrations, use `./create_migration.sh my_migration_name` to modify the database schema
|
||||
* [pubsub](https://github.com/coder/coder/tree/main/coderd/database/pubsub): PubSub implementation using PostgreSQL and in-memory drop-in replacement
|
||||
* [queries](https://github.com/coder/coder/tree/main/coderd/database/queries): contains SQL files with queries, `sqlc` compiles them to [Go functions](https://github.com/coder/coder/blob/main/coderd/database/queries.sql.go)
|
||||
* [sqlc.yaml](https://github.com/coder/coder/tree/main/coderd/database/sqlc.yaml): defines mappings between SQL types and custom Go structures
|
||||
* [codersdk](https://github.com/coder/coder/tree/main/codersdk): user-facing API entities used by CLI and site to communicate with `coderd` endpoints
|
||||
* [dogfood](https://github.com/coder/coder/tree/main/dogfood): Terraform definition of the dogfood cluster deployment
|
||||
* [enterprise](https://github.com/coder/coder/tree/main/enterprise): enterprise-only features, notice similar file structure to repository root (`audit`, `cli`, `cmd`, `coderd`, etc.)
|
||||
* [coderd](https://github.com/coder/coder/tree/main/enterprise/coderd)
|
||||
* [prebuilds](https://github.com/coder/coder/tree/main/enterprise/coderd/prebuilds): core logic of prebuilt workspaces - reconciliation loop
|
||||
* [provisioner](https://github.com/coder/coder/tree/main/provisioner): supported implementation of provisioners, Terraform and "echo" (for testing purposes)
|
||||
* [provisionerd](https://github.com/coder/coder/tree/main/provisionerd): core logic of provisioner runner to interact provisionerd server, depending on a job acquired it calls template import, dry run or a workspace build
|
||||
* [pty](https://github.com/coder/coder/tree/main/pty): terminal emulation for agent shell
|
||||
* [support](https://github.com/coder/coder/tree/main/support): compile a support bundle with diagnostics
|
||||
* [tailnet](https://github.com/coder/coder/tree/main/tailnet): core logic of Tailnet controller to maintain DERP maps, coordinate connections with agents and peers
|
||||
* [vpn](https://github.com/coder/coder/tree/main/vpn): Coder Desktop (VPN) and tunneling components
|
||||
* [agent](../../../agent): core logic of a workspace agent, supports DevContainers, remote SSH, startup/shutdown script execution. Protobuf definitions for DRPC communication with `coderd` are kept in [proto](../../../agent/proto).
|
||||
* [cli](../../../cli): CLI interface for `coder` command built on [coder/serpent](https://github.com/coder/serpent). Input controls are defined in [cliui](../../../cli/cliui), and [testdata](../../../cli/testdata) contains golden files for common CLI calls
|
||||
* [cmd](../../../cmd): entry points for CLI and services, including `coderd`
|
||||
* [coderd](../../../coderd): the main API server implementation with [chi](https://github.com/go-chi/chi) endpoints
|
||||
* [audit](../../../coderd/audit): audit log logic, defines target resources, actions and extra fields
|
||||
* [autobuild](../../../coderd/autobuild): core logic of the workspace autobuild executor, periodically evaluates workspaces for next transition actions
|
||||
* [httpmw](../../../coderd/httpmw): HTTP middlewares mainly used to extract parameters from HTTP requests (e.g. current user, template, workspace, OAuth2 account, etc.) and storing them in the request context
|
||||
* [prebuilds](../../../coderd/prebuilds): common interfaces for prebuild workspaces, feature implementation is in [enterprise/prebuilds](../../../enterprise/coderd/prebuilds)
|
||||
* [provisionerdserver](../../../coderd/provisionerdserver): DRPC server for [provisionerd](../../../provisionerd) instances, used to validate and extract Terraform data and resources, and store them in the database.
|
||||
* [rbac](../../../coderd/rbac): RBAC engine for `coderd`, including authz layer, role definitions and custom roles. Built on top of [Open Policy Agent](https://github.com/open-policy-agent/opa) and Rego policies.
|
||||
* [telemetry](../../../coderd/telemetry): records a snapshot with various workspace data for telemetry purposes. Once recorded the reporter sends it to the configured telemetry endpoint.
|
||||
* [tracing](../../../coderd/tracing): extends telemetry with tracing data consistent with [OpenTelemetry specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md)
|
||||
* [workspaceapps](../../../coderd/workspaceapps): core logic of a secure proxy to expose workspace apps deployed in a workspace
|
||||
* [wsbuilder](../../../coderd/wsbuilder): wrapper for business logic of creating a workspace build. It encapsulates all database operations required to insert a build record in a transaction.
|
||||
* [database](../../../coderd/database): schema migrations, query logic, in-memory database, etc.
|
||||
* [db2sdk](../../../coderd/database/db2sdk): translation between database structures and [codersdk](../../../codersdk) objects used by coderd API.
|
||||
* [dbauthz](../../../coderd/database/dbauthz): AuthZ wrappers for database queries, ideally, every query should verify first if the accessor is eligible to see the query results.
|
||||
* [dbfake](../../../coderd/database/dbfake): helper functions to quickly prepare the initial database state for testing purposes (e.g. create N healthy workspaces and templates), operates on higher level than [dbgen](../../../coderd/database/dbgen)
|
||||
* [dbgen](../../../coderd/database/dbgen): helper functions to insert raw records to the database store, used for testing purposes
|
||||
* [dbmock](../../../coderd/database/dbmock): a store wrapper for database queries, useful to verify if the function has been called, used for testing purposes
|
||||
* [dbpurge](../../../coderd/database/dbpurge): simple wrapper for periodic database cleanup operations
|
||||
* [migrations](../../../coderd/database/migrations): an ordered list of up/down database migrations, use `./create_migration.sh my_migration_name` to modify the database schema
|
||||
* [pubsub](../../../coderd/database/pubsub): PubSub implementation using PostgreSQL and in-memory drop-in replacement
|
||||
* [queries](../../../coderd/database/queries): contains SQL files with queries, `sqlc` compiles them to [Go functions](../../../coderd/database/queries.sql.go)
|
||||
* [sqlc.yaml](../../../coderd/database/sqlc.yaml): defines mappings between SQL types and custom Go structures
|
||||
* [codersdk](../../../codersdk): user-facing API entities used by CLI and site to communicate with `coderd` endpoints
|
||||
* [dogfood](../../../dogfood): Terraform definition of the dogfood cluster deployment
|
||||
* [enterprise](../../../enterprise): enterprise-only features, notice similar file structure to repository root (`audit`, `cli`, `cmd`, `coderd`, etc.)
|
||||
* [coderd](../../../enterprise/coderd)
|
||||
* [prebuilds](../../../enterprise/coderd/prebuilds): core logic of prebuilt workspaces - reconciliation loop
|
||||
* [provisioner](../../../provisioner): supported implementation of provisioners, Terraform and "echo" (for testing purposes)
|
||||
* [provisionerd](../../../provisionerd): core logic of provisioner runner to interact provisionerd server, depending on a job acquired it calls template import, dry run or a workspace build
|
||||
* [pty](../../../pty): terminal emulation for agent shell
|
||||
* [support](../../../support): compile a support bundle with diagnostics
|
||||
* [tailnet](../../../tailnet): core logic of Tailnet controller to maintain DERP maps, coordinate connections with agents and peers
|
||||
* [vpn](../../../vpn): Coder Desktop (VPN) and tunneling components
|
||||
|
||||
## Testing
|
||||
|
||||
The Coder backend includes a rich suite of unit and end-to-end tests. A variety of helper utilities are used throughout the codebase to make testing easier, more consistent, and closer to real behavior.
|
||||
|
||||
### [clitest](https://github.com/coder/coder/tree/main/cli/clitest)
|
||||
### [clitest](../../../cli/clitest)
|
||||
|
||||
* Spawns an in-memory `serpent.Command` instance for unit testing
|
||||
* Configures an authorized `codersdk` client
|
||||
* Once a `serpent.Invocation` is created, tests can execute commands as if invoked by a real user
|
||||
|
||||
### [ptytest](https://github.com/coder/coder/tree/main/pty/ptytest)
|
||||
### [ptytest](../../../pty/ptytest)
|
||||
|
||||
* `ptytest` attaches to a `serpent.Invocation` and simulates TTY input/output
|
||||
* `pty` provides matchers and "write" operations for interacting with pseudo-terminals
|
||||
|
||||
### [coderdtest](https://github.com/coder/coder/tree/main/coderd/coderdtest)
|
||||
### [coderdtest](../../../coderd/coderdtest)
|
||||
|
||||
* Provides shortcuts to spin up an in-memory `coderd` instance
|
||||
* Can start an embedded provisioner daemon
|
||||
* Supports multi-user testing via `CreateFirstUser` and `CreateAnotherUser`
|
||||
* Includes "busy wait" helpers like `AwaitTemplateVersionJobCompleted`
|
||||
* [oidctest](https://github.com/coder/coder/tree/main/coderd/coderdtest/oidctest) can start a fake OIDC provider
|
||||
* [oidctest](../../../coderd/coderdtest/oidctest) can start a fake OIDC provider
|
||||
|
||||
### [testutil](https://github.com/coder/coder/tree/main/testutil)
|
||||
### [testutil](../../../testutil)
|
||||
|
||||
* General-purpose testing utilities, including:
|
||||
* [chan.go](https://github.com/coder/coder/blob/main/testutil/chan.go): helpers for sending/receiving objects from channels (`TrySend`, `RequireReceive`, etc.)
|
||||
* [duration.go](https://github.com/coder/coder/blob/main/testutil/duration.go): set timeouts for test execution
|
||||
* [eventually.go](https://github.com/coder/coder/blob/main/testutil/eventually.go): repeatedly poll for a condition using a ticker
|
||||
* [port.go](https://github.com/coder/coder/blob/main/testutil/port.go): select a free random port
|
||||
* [prometheus.go](https://github.com/coder/coder/blob/main/testutil/prometheus.go): validate Prometheus metrics with expected values
|
||||
* [pty.go](https://github.com/coder/coder/blob/main/testutil/pty.go): read output from a terminal until a condition is met
|
||||
* [wait_buffer.go](https://github.com/coder/coder/blob/main/testutil/wait_buffer.go): thread-safe `io.Writer` that blocks until accumulated output contains a signal (`WaitFor`, `WaitForNth`, `WaitForCond`)
|
||||
* [chan.go](../../../testutil/chan.go): helpers for sending/receiving objects from channels (`TrySend`, `RequireReceive`, etc.)
|
||||
* [duration.go](../../../testutil/duration.go): set timeouts for test execution
|
||||
* [eventually.go](../../../testutil/eventually.go): repeatedly poll for a condition using a ticker
|
||||
* [port.go](../../../testutil/port.go): select a free random port
|
||||
* [prometheus.go](../../../testutil/prometheus.go): validate Prometheus metrics with expected values
|
||||
* [pty.go](../../../testutil/pty.go): read output from a terminal until a condition is met
|
||||
* [wait_buffer.go](../../../testutil/wait_buffer.go): thread-safe `io.Writer` that blocks until accumulated output contains a signal (`WaitFor`, `WaitForNth`, `WaitForCond`)
|
||||
|
||||
### [dbtestutil](https://github.com/coder/coder/tree/main/coderd/database/dbtestutil)
|
||||
### [dbtestutil](../../../coderd/database/dbtestutil)
|
||||
|
||||
* Allows choosing between real and in-memory database backends for tests
|
||||
* `WillUsePostgres` is useful for skipping tests in CI environments that don't run Postgres
|
||||
@@ -169,9 +169,9 @@ There are two types of fixtures that are used to test that migrations don't
|
||||
break existing Coder deployments:
|
||||
|
||||
* Partial fixtures
|
||||
[`migrations/testdata/fixtures`](https://github.com/coder/coder/tree/main/coderd/database/migrations/testdata/fixtures)
|
||||
[`migrations/testdata/fixtures`](../../../coderd/database/migrations/testdata/fixtures)
|
||||
* Full database dumps
|
||||
[`migrations/testdata/full_dumps`](https://github.com/coder/coder/tree/main/coderd/database/migrations/testdata/full_dumps)
|
||||
[`migrations/testdata/full_dumps`](../../../coderd/database/migrations/testdata/full_dumps)
|
||||
|
||||
Both types behave like database migrations (they also
|
||||
[`migrate`](https://github.com/golang-migrate/migrate)). Their behavior mirrors
|
||||
@@ -194,7 +194,7 @@ To add a new partial fixture, run the following command:
|
||||
```
|
||||
|
||||
Then add some queries to insert data and commit the file to the repo. See
|
||||
[`000024_example.up.sql`](https://github.com/coder/coder/blob/main/coderd/database/migrations/testdata/fixtures/000024_example.up.sql)
|
||||
[`000024_example.up.sql`](../../../coderd/database/migrations/testdata/fixtures/000024_example.up.sql)
|
||||
for an example.
|
||||
|
||||
To create a full dump, run a fully fledged Coder deployment and use it to
|
||||
|
||||
@@ -4,7 +4,7 @@ We scale-test Coder with a built-in utility that can
|
||||
be used in your environment for insights into how Coder scales with your
|
||||
infrastructure. For scale-testing Kubernetes clusters we recommend that you install
|
||||
and use the dedicated Coder template,
|
||||
[scaletest-runner](https://github.com/coder/coder/tree/main/scaletest/templates/scaletest-runner).
|
||||
[scaletest-runner](../../../scaletest/templates/scaletest-runner).
|
||||
|
||||
Learn more about [Coder’s architecture](./architecture.md) and our
|
||||
[scale-testing methodology](./scale-testing.md).
|
||||
@@ -138,7 +138,7 @@ This will delete all workspaces and users with the prefix `scaletest-`.
|
||||
## Scale testing template
|
||||
|
||||
Consider using a dedicated
|
||||
[scaletest-runner](https://github.com/coder/coder/tree/main/scaletest/templates/scaletest-runner)
|
||||
[scaletest-runner](../../../scaletest/templates/scaletest-runner)
|
||||
template alongside the CLI utility for testing large-scale Kubernetes clusters.
|
||||
|
||||
The template deploys a main workspace with scripts used to orchestrate Coder,
|
||||
@@ -177,7 +177,7 @@ Scale testing concurrency can be controlled with the following parameters:
|
||||
It is recommended to learn how to operate the _scaletest-runner_ before running
|
||||
it against the staging cluster (or production at your own risk). Coder provides
|
||||
different
|
||||
[workspace configurations](https://github.com/coder/coder/tree/main/scaletest/templates)
|
||||
[workspace configurations](../../../scaletest/templates)
|
||||
that operators can deploy depending on the traffic projections.
|
||||
|
||||
There are a few cluster options available:
|
||||
@@ -205,7 +205,7 @@ Use this template variant to verify limits of the cluster performance.
|
||||
|
||||
During scale tests, operators can monitor progress using a Grafana dashboard.
|
||||
Coder offers a comprehensive overview
|
||||
[dashboard](https://github.com/coder/coder/blob/main/scaletest/scaletest_dashboard.json)
|
||||
[dashboard](../../../scaletest/scaletest_dashboard.json)
|
||||
that can seamlessly integrate into the internal Grafana deployment.
|
||||
|
||||
This dashboard provides insights into various aspects, including:
|
||||
|
||||
@@ -157,7 +157,7 @@ to schedule the control plane pods on the appropriate node group.
|
||||
|
||||
Coder workspaces can be deployed either as Pods or Deployments in Kubernetes.
|
||||
See our
|
||||
[example Kubernetes workspace template](https://github.com/coder/coder/tree/main/examples/templates/kubernetes).
|
||||
[example Kubernetes workspace template](../../../../examples/templates/kubernetes).
|
||||
Configure the workspace node group to be auto-scaling, to dynamically allocate
|
||||
compute as users start/stop workspaces at the beginning and end of their day.
|
||||
Set nodeSelectors, affinities, and tolerations in Coder templates to assign
|
||||
@@ -378,7 +378,7 @@ could affect workspace users experience once the platform is live.
|
||||
### Helm Chart Configuration
|
||||
|
||||
1. Reference our
|
||||
[Helm chart values file](https://github.com/coder/coder/blob/main/helm/coder/values.yaml)
|
||||
[Helm chart values file](../../../../helm/coder/values.yaml)
|
||||
and identify the required values for deployment.
|
||||
1. Create a `values.yaml` and add it to your version control system.
|
||||
1. Determine the necessary environment variables. Here is the
|
||||
|
||||
@@ -16,7 +16,7 @@ choose a template from the
|
||||
|
||||
1. In the Coder dashboard, select **Templates** then **Create Template**.
|
||||
1. Use a
|
||||
[starter template](https://github.com/coder/coder/tree/main/examples/templates)
|
||||
[starter template](../../../../../examples/templates)
|
||||
or create a new template:
|
||||
|
||||
- Starter template:
|
||||
@@ -119,12 +119,12 @@ their development environments:
|
||||
|
||||
## Example templates
|
||||
|
||||
| Template | Description |
|
||||
|---------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Docker dev containers](https://github.com/coder/coder/tree/main/examples/templates/docker-devcontainer) | Docker provisions a development container. |
|
||||
| [Kubernetes dev containers](https://github.com/coder/coder/tree/main/examples/templates/kubernetes-devcontainer) | Provisions a development container on the Kubernetes cluster. |
|
||||
| [Google Compute Engine dev container](https://github.com/coder/coder/tree/main/examples/templates/gcp-devcontainer) | Runs a development container inside a single GCP instance. It also mounts the Docker socket from the VM inside the container to enable Docker inside the workspace. |
|
||||
| [AWS EC2 dev container](https://github.com/coder/coder/tree/main/examples/templates/aws-devcontainer) | Runs a development container inside a single EC2 instance. It also mounts the Docker socket from the VM inside the container to enable Docker inside the workspace. |
|
||||
| Template | Description |
|
||||
|-------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| [Docker dev containers](../../../../../examples/templates/docker-devcontainer) | Docker provisions a development container. |
|
||||
| [Kubernetes dev containers](../../../../../examples/templates/kubernetes-devcontainer) | Provisions a development container on the Kubernetes cluster. |
|
||||
| [Google Compute Engine dev container](../../../../../examples/templates/gcp-devcontainer) | Runs a development container inside a single GCP instance. It also mounts the Docker socket from the VM inside the container to enable Docker inside the workspace. |
|
||||
| [AWS EC2 dev container](../../../../../examples/templates/aws-devcontainer) | Runs a development container inside a single EC2 instance. It also mounts the Docker socket from the VM inside the container to enable Docker inside the workspace. |
|
||||
|
||||
Your template can prompt the user for a repo URL with
|
||||
[parameters](../../../templates/extending-templates/parameters.md):
|
||||
|
||||
@@ -305,7 +305,7 @@ With autostart enabled:
|
||||
|
||||
## Example Template
|
||||
|
||||
The [Docker (Dev Containers)](https://github.com/coder/coder/tree/main/examples/templates/docker-devcontainer)
|
||||
The [Docker (Dev Containers)](../../../../examples/templates/docker-devcontainer)
|
||||
starter template demonstrates Dev Containers integration using Docker-in-Docker.
|
||||
It includes the `devcontainers-cli` module, `git-clone` module, and the
|
||||
`coder_devcontainer` resource.
|
||||
|
||||
@@ -126,7 +126,7 @@ To set this up, follow these steps:
|
||||
> [!NOTE]
|
||||
> The admin-level access token is used to provision user tokens and is never exposed to developers or stored in workspaces.
|
||||
|
||||
If you don't want to use the official modules, you can read through the [example template](https://github.com/coder/coder/tree/main/examples/jfrog/docker), which uses Docker as the underlying compute. The
|
||||
If you don't want to use the official modules, you can read through the [example template](../../../examples/jfrog/docker), which uses Docker as the underlying compute. The
|
||||
same concepts apply to all compute types.
|
||||
|
||||
## Air-Gapped Deployments
|
||||
@@ -135,7 +135,7 @@ See the [air-gapped deployments](../templates/extending-templates/modules.md#off
|
||||
|
||||
## Next Steps
|
||||
|
||||
- See the [full example Docker template](https://github.com/coder/coder/tree/main/examples/jfrog/docker).
|
||||
- See the [full example Docker template](../../../examples/jfrog/docker).
|
||||
|
||||
- To serve extensions from your own VS Code Marketplace, check out
|
||||
[code-marketplace](https://github.com/coder/code-marketplace#artifactory-storage).
|
||||
|
||||
@@ -57,7 +57,7 @@ If you deployed Coder on a VM, copy the kubeconfig file to
|
||||
### Create a Coder template
|
||||
|
||||
You can start from our
|
||||
[example template](https://github.com/coder/coder/tree/main/examples/templates/kubernetes).
|
||||
[example template](../../../examples/templates/kubernetes).
|
||||
From there, add
|
||||
[template parameters](../templates/extending-templates/parameters.md) to allow
|
||||
developers to pick their desired cluster.
|
||||
@@ -158,7 +158,7 @@ rolebinding.rbac.authorization.k8s.io/coder-v2 created
|
||||
### 2. Modify the Kubernetes template
|
||||
|
||||
You can start from our
|
||||
[example template](https://github.com/coder/coder/tree/main/examples/templates/kubernetes).
|
||||
[example template](../../../examples/templates/kubernetes).
|
||||
|
||||
```tf
|
||||
variable "host" {
|
||||
|
||||
@@ -239,7 +239,7 @@ eval $(./setup-test-app.sh)
|
||||
./cleanup-test-app.sh
|
||||
```
|
||||
|
||||
For more details on testing, see the [OAuth2 test scripts README](https://github.com/coder/coder/blob/main/scripts/oauth2/README.md).
|
||||
For more details on testing, see the [OAuth2 test scripts README](../../../scripts/oauth2/README.md).
|
||||
|
||||
## Common Issues
|
||||
|
||||
|
||||
@@ -20,4 +20,4 @@ You can change your deployment custom Terraform binary as long as it is in
|
||||
`PATH` and is within the
|
||||
[supported versions](https://github.com/coder/coder/blob/f57ce97b5aadd825ddb9a9a129bb823a3725252b/provisioner/terraform/install.go#L22-L25).
|
||||
The hardcoded version check ensures compatibility with our
|
||||
[example templates](https://github.com/coder/coder/tree/main/examples/templates).
|
||||
[example templates](../../../examples/templates).
|
||||
|
||||
@@ -30,7 +30,7 @@ coderd_api_active_users_duration_hour 0
|
||||
|
||||
### Kubernetes deployment
|
||||
|
||||
The Prometheus endpoint can be enabled in the [Helm chart's](https://github.com/coder/coder/tree/main/helm)
|
||||
The Prometheus endpoint can be enabled in the [Helm chart's](../../../helm)
|
||||
`values.yml` by setting `CODER_PROMETHEUS_ENABLE=true`. Once enabled, the environment variable `CODER_PROMETHEUS_ADDRESS` will be set by default to
|
||||
`0.0.0.0:2112`. A Service Endpoint will not be exposed; if you need to
|
||||
expose the Prometheus port on a Service, (for example, to use a
|
||||
|
||||
@@ -178,7 +178,7 @@ regular Coder server.
|
||||
#### Docker Compose
|
||||
|
||||
Change the provided
|
||||
[`compose.yml`](https://github.com/coder/coder/blob/main/compose.yaml)
|
||||
[`compose.yml`](../../../compose.yaml)
|
||||
file to include a custom entrypoint:
|
||||
|
||||
```diff
|
||||
|
||||
@@ -162,7 +162,7 @@ This can also be done in the UI when building a template:
|
||||

|
||||
|
||||
Alternatively, a template can target a provisioner via
|
||||
[workspace tags](https://github.com/coder/coder/tree/main/examples/workspace-tags)
|
||||
[workspace tags](../../../examples/workspace-tags)
|
||||
inside the Terraform. See the
|
||||
[workspace tags documentation](../../admin/templates/extending-templates/workspace-tags.md)
|
||||
for more information.
|
||||
@@ -332,7 +332,7 @@ will use in concert with the Helm chart for deploying the Coder server.
|
||||
created. The set of tags is inferred automatically from the provisioner key.
|
||||
|
||||
> Refer to the
|
||||
> [values.yaml](https://github.com/coder/coder/blob/main/helm/provisioner/values.yaml)
|
||||
> [values.yaml](../../../helm/provisioner/values.yaml)
|
||||
> file for the coder-provisioner chart for information on what values can be
|
||||
> specified.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ For other security tips, visit our guide to
|
||||
|
||||
> [!CAUTION]
|
||||
> If you discover a vulnerability in Coder, please do not hesitate to report it
|
||||
> to us by following the [security policy](https://github.com/coder/coder/blob/main/SECURITY.md).
|
||||
> to us by following the [security policy](../../../SECURITY.md).
|
||||
|
||||
Security advisories are published on the
|
||||
[GitHub Security Advisories](https://github.com/coder/coder/security/advisories)
|
||||
|
||||
@@ -56,7 +56,7 @@ If you are providing TLS certificates directly to the Coder server, either
|
||||
|
||||
1. Use a single certificate and key for both the root and wildcard domains.
|
||||
1. Configure multiple certificates and keys via
|
||||
[`coder.tls.secretNames`](https://github.com/coder/coder/blob/main/helm/coder/values.yaml)
|
||||
[`coder.tls.secretNames`](../../../helm/coder/values.yaml)
|
||||
in the Helm Chart, or
|
||||
[`--tls-cert-file`](../../reference/cli/server.md#--tls-cert-file) and
|
||||
[`--tls-key-file`](../../reference/cli/server.md#--tls-key-file) command line
|
||||
|
||||
@@ -10,7 +10,7 @@ the data.
|
||||
## What we collect
|
||||
|
||||
You can find a full list of the data we collect in our source code
|
||||
[here](https://github.com/coder/coder/blob/main/coderd/telemetry/telemetry.go).
|
||||
[here](../../../coderd/telemetry/telemetry.go).
|
||||
In particular, look at the struct types such as `Template` or `Workspace`.
|
||||
|
||||
As a rule, we **do not collect** the following types of information:
|
||||
|
||||
@@ -142,7 +142,7 @@ nodes. Refer to sysbox's
|
||||
to ensure your nodes are compliant.
|
||||
|
||||
To get started with `envbox` check out the
|
||||
[starter template](https://github.com/coder/coder/tree/main/examples/templates/kubernetes-envbox)
|
||||
[starter template](../../../../examples/templates/kubernetes-envbox)
|
||||
or visit the [repo](https://github.com/coder/envbox).
|
||||
|
||||
### Authenticating with a Private Registry
|
||||
|
||||
@@ -17,7 +17,7 @@ authenticate. After that, Coder will store and refresh tokens for future
|
||||
operations.
|
||||
|
||||
<video autoplay playsinline loop>
|
||||
<source src="https://github.com/coder/coder/blob/main/site/static/external-auth.mp4?raw=true" type="video/mp4">
|
||||
<source src="../../../../site/static/external-auth.mp4?raw=true" type="video/mp4">
|
||||
Your browser does not support the video tag.
|
||||
</video>
|
||||
|
||||
|
||||
@@ -54,7 +54,7 @@ come bundled with your Coder deployment.
|
||||
Coder is distributed with a bundle of icons for popular cloud providers and
|
||||
programming languages. You can see all of the icons (or suggest new ones) in our
|
||||
repository on
|
||||
[GitHub](https://github.com/coder/coder/tree/main/site/static/icon).
|
||||
[GitHub](../../../../site/static/icon).
|
||||
|
||||
You can also view the entire list, with search and previews, by navigating to
|
||||
`/icons` on your Coder deployment (for example,
|
||||
|
||||
@@ -6,7 +6,7 @@ templates using the
|
||||
[Coder Terraform provider](https://registry.terraform.io/providers/coder/coder/latest/docs).
|
||||
The provider docs will provide code examples for usage; alternatively, you can
|
||||
view our
|
||||
[example templates](https://github.com/coder/coder/tree/main/examples/templates)
|
||||
[example templates](../../../../examples/templates)
|
||||
to get started.
|
||||
|
||||
## Workspace agents
|
||||
|
||||
@@ -122,9 +122,9 @@ Based on the instructions
|
||||
#### Example template
|
||||
|
||||
We have an example template
|
||||
[here](https://github.com/coder/coder/blob/main/examples/jfrog/remote/main.tf)
|
||||
[here](../../../../examples/jfrog/remote/main.tf)
|
||||
that uses our
|
||||
[JFrog Docker](https://github.com/coder/coder/blob/main/examples/jfrog/docker/main.tf)
|
||||
[JFrog Docker](../../../../examples/jfrog/docker/main.tf)
|
||||
template as the underlying module.
|
||||
|
||||
### Private git repository
|
||||
|
||||
@@ -37,7 +37,7 @@ data "coder_workspace_tags" "custom_workspace_tags" {
|
||||
`feature_cache_enabled`
|
||||
|
||||
Review the
|
||||
[full template example](https://github.com/coder/coder/tree/main/examples/workspace-tags)
|
||||
[full template example](../../../../examples/workspace-tags)
|
||||
using `coder_workspace_tags` and `coder_parameter`s.
|
||||
|
||||
## How it Works
|
||||
|
||||
@@ -58,7 +58,7 @@ resource "coderd_template" "kubernetes" {
|
||||
```
|
||||
|
||||
For an example, see how we push our development image and template
|
||||
[with GitHub actions](https://github.com/coder/coder/blob/main/.github/workflows/dogfood.yaml).
|
||||
[with GitHub actions](../../../../.github/workflows/dogfood.yaml).
|
||||
|
||||
## Coder CLI
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ dependencies to work in your network and work with Coder. Here are some things
|
||||
to consider:
|
||||
|
||||
- `curl`, `wget`, or `busybox` is required to download and run
|
||||
[the agent](https://github.com/coder/coder/blob/main/provisionersdk/scripts/bootstrap_linux.sh)
|
||||
[the agent](../../../../provisionersdk/scripts/bootstrap_linux.sh)
|
||||
- `git` is recommended so developers can clone repositories
|
||||
- If the Coder server is using a certificate from an internal certificate
|
||||
authority (CA), you'll need to add or mount these into your image
|
||||
|
||||
@@ -28,13 +28,13 @@ If you prefer to use Coder on the
|
||||
[command line](../../../reference/cli/index.md), `coder templates init`.
|
||||
|
||||
Coder starter templates are also available on our
|
||||
[GitHub repo](https://github.com/coder/coder/tree/main/examples/templates).
|
||||
[GitHub repo](../../../../examples/templates).
|
||||
|
||||
## Community Templates
|
||||
|
||||
As well as Coder's starter templates, you can see a list of community templates
|
||||
by our users
|
||||
[here](https://github.com/coder/coder/blob/main/examples/templates/community-templates.md).
|
||||
[here](../../../../examples/templates/community-templates.md).
|
||||
|
||||
## Editing templates
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ You can embed an "Open in Coder" button into your git repos or internal wikis to
|
||||
let developers quickly launch a new workspace.
|
||||
|
||||
<video autoplay playsinline loop>
|
||||
<source src="https://github.com/coder/coder/blob/main/docs/images/templates/open-in-coder.mp4?raw=true" type="video/mp4">
|
||||
<source src="../../images/templates/open-in-coder.mp4?raw=true" type="video/mp4">
|
||||
Your browser does not support the video tag.
|
||||
</video>
|
||||
|
||||
|
||||
@@ -8,7 +8,7 @@ has failed or timed out.
|
||||
## Agent connection issues
|
||||
|
||||
If the agent is not connected, it means the agent or
|
||||
[init script](https://github.com/coder/coder/tree/main/provisionersdk/scripts)
|
||||
[init script](../../../provisionersdk/scripts)
|
||||
has failed on the resource.
|
||||
|
||||
```console
|
||||
|
||||
@@ -84,7 +84,7 @@ For a basic recommendation of what to allow for agents, see the
|
||||
[Anthropic documentation on default allowed domains](https://code.claude.com/docs/en/claude-code-on-the-web#default-allowed-domains).
|
||||
For a comprehensive example of a production Agent Firewall configuration, see
|
||||
the
|
||||
[Coder dogfood policy example](https://github.com/coder/coder/blob/main/dogfood/coder/boundary-config.yaml).
|
||||
[Coder dogfood policy example](../../../dogfood/coder/boundary-config.yaml).
|
||||
|
||||
To load the policy from a `config.yaml` file in your template directory instead,
|
||||
pass it via `agent_firewall_config`. The module writes the config to the workspace
|
||||
|
||||
@@ -11,7 +11,7 @@ AI Gateway records the last `user` prompt, token usage, model reasoning, and eve
|
||||
|
||||

|
||||
|
||||
We provide an example Grafana dashboard that you can import as a starting point for your metrics. See [the Grafana dashboard README](https://github.com/coder/coder/blob/main/examples/monitoring/dashboards/grafana/aibridge/README.md).
|
||||
We provide an example Grafana dashboard that you can import as a starting point for your metrics. See [the Grafana dashboard README](../../../examples/monitoring/dashboards/grafana/aibridge/README.md).
|
||||
|
||||
These logs and metrics can be used to determine usage patterns, track costs, and evaluate tooling adoption.
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
|
||||
## Implementation Details
|
||||
|
||||
`coderd` runs an in-memory instance of `aibridged`, whose logic is mostly contained in https://github.com/coder/coder/tree/main/aibridge. In future releases we will support running external instances for higher throughput and complete memory isolation from `coderd`.
|
||||
`coderd` runs an in-memory instance of `aibridged`, whose logic is mostly contained in ../../../aibridge. In future releases we will support running external instances for higher throughput and complete memory isolation from `coderd`.
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -54,7 +54,7 @@ Try prompts such as:
|
||||
- "document the project structure"
|
||||
- "change the primary color theme to purple"
|
||||
|
||||
To import the template and begin configuring it, import the example [Run Coder Tasks on Docker](https://github.com/coder/coder/tree/main/examples/templates/tasks-docker) template.
|
||||
To import the template and begin configuring it, import the example [Run Coder Tasks on Docker](../../examples/templates/tasks-docker) template.
|
||||
|
||||
### Option 2) Create or Duplicate Your Own Template
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ air-gapped with Kubernetes or Docker.
|
||||
|
||||
| | Public deployments | Air-gapped deployments |
|
||||
|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Terraform binary | By default, Coder downloads Terraform binary from [releases.hashicorp.com](https://releases.hashicorp.com) | Terraform binary must be included in `PATH` for the VM or container image. [Supported versions](https://github.com/coder/coder/blob/main/provisioner/terraform/install.go#L23-L24) |
|
||||
| Terraform binary | By default, Coder downloads Terraform binary from [releases.hashicorp.com](https://releases.hashicorp.com) | Terraform binary must be included in `PATH` for the VM or container image. [Supported versions](../../provisioner/terraform/install.go#L23-L24) |
|
||||
| Terraform registry | Coder templates will attempt to download providers from [registry.terraform.io](https://registry.terraform.io) or [custom source addresses](https://developer.hashicorp.com/terraform/language/providers/requirements#source-addresses) specified in each template | [Custom source addresses](https://developer.hashicorp.com/terraform/language/providers/requirements#source-addresses) can be specified in each Coder template, or a custom registry/mirror can be used. More details below |
|
||||
| STUN | By default, Coder uses Google's public STUN server for direct workspace connections | STUN can be safely [disabled](../reference/cli/server.md#--derp-server-stun-addresses) users can still connect via [relayed connections](../admin/networking/index.md#-geo-distribution). Alternatively, you can set a [custom DERP server](../reference/cli/server.md#--derp-server-stun-addresses) |
|
||||
| DERP | By default, Coder's built-in DERP relay can be used, or [Tailscale's public relays](../admin/networking/index.md#relayed-connections). | By default, Coder's built-in DERP relay can be used, or [custom relays](../admin/networking/index.md#custom-relays). |
|
||||
@@ -33,7 +33,7 @@ following:
|
||||
|
||||
> [!NOTE]
|
||||
> Coder includes the latest
|
||||
> [supported version](https://github.com/coder/coder/blob/main/provisioner/terraform/install.go#L23-L24)
|
||||
> [supported version](../../provisioner/terraform/install.go#L23-L24)
|
||||
> of Terraform in the official Docker images. If you need to bundle a different
|
||||
> version of terraform, you can do so by customizing the image.
|
||||
|
||||
@@ -50,10 +50,10 @@ RUN apk add curl unzip
|
||||
RUN mkdir -p /opt/terraform
|
||||
|
||||
# Terraform is already included in the official Coder image.
|
||||
# See https://github.com/coder/coder/blob/main/scripts/Dockerfile.base#L15
|
||||
# See ../../scripts/Dockerfile.base#L15
|
||||
# If you need to install a different version of Terraform, you can do so here.
|
||||
# The below step is optional if you wish to keep the existing version.
|
||||
# See https://github.com/coder/coder/blob/main/provisioner/terraform/install.go#L23-L24
|
||||
# See ../../provisioner/terraform/install.go#L23-L24
|
||||
# for supported Terraform versions.
|
||||
ARG TERRAFORM_VERSION=1.11.0
|
||||
RUN apk update && \
|
||||
@@ -115,7 +115,7 @@ ENV TF_CLI_CONFIG_FILE=/home/coder/.terraformrc
|
||||
> [!NOTE]
|
||||
> If you are bundling Terraform providers into your Coder image, be sure the
|
||||
> provider version matches any templates or
|
||||
> [example templates](https://github.com/coder/coder/tree/main/examples/templates)
|
||||
> [example templates](../../examples/templates)
|
||||
> you intend to use.
|
||||
|
||||
```tf
|
||||
|
||||
@@ -29,7 +29,7 @@ deployments and you should adjust your infrastructure when preparing for
|
||||
production use. See: [Scaling Coder](../../admin/infrastructure/index.md)
|
||||
|
||||
<video autoplay playsinline loop>
|
||||
<source src="https://github.com/coder/coder/blob/main/docs/images/platforms/gcp/launch.mp4?raw=true" type="video/mp4">
|
||||
<source src="../../images/platforms/gcp/launch.mp4?raw=true" type="video/mp4">
|
||||
Your browser does not support the video tag.
|
||||
</video>
|
||||
|
||||
@@ -65,12 +65,12 @@ sudo systemctl restart coder # restart Coder
|
||||
|
||||
Instead of running containers on the Coder instance, you can offer developers
|
||||
full VM instances with the
|
||||
[gcp-linux](https://github.com/coder/coder/tree/main/examples/templates/gcp-linux)
|
||||
[gcp-linux](../../../examples/templates/gcp-linux)
|
||||
template.
|
||||
|
||||
Before you can use this template, you must authorize Coder to create VM
|
||||
instances in your GCP project. Follow the instructions in the
|
||||
[gcp-linux template README](https://github.com/coder/coder/tree/main/examples/templates/gcp-linux#authentication)
|
||||
[gcp-linux template README](../../../examples/templates/gcp-linux#authentication)
|
||||
to set up authentication.
|
||||
|
||||
### Next Steps
|
||||
|
||||
@@ -23,14 +23,14 @@ You can install and run Coder using the official Docker images published on
|
||||
## Install Coder via `docker compose`
|
||||
|
||||
Coder publishes a
|
||||
[docker compose example](https://github.com/coder/coder/blob/main/compose.yaml)
|
||||
[docker compose example](../../compose.yaml)
|
||||
which includes a PostgreSQL container and volume.
|
||||
|
||||
1. Make sure you have [Docker Compose](https://docs.docker.com/compose/install/)
|
||||
installed.
|
||||
|
||||
1. Download the
|
||||
[`docker-compose.yaml`](https://github.com/coder/coder/blob/main/compose.yaml)
|
||||
[`docker-compose.yaml`](../../compose.yaml)
|
||||
file.
|
||||
|
||||
1. Update `group_add:` in `docker-compose.yaml` with the `gid` of `docker`
|
||||
|
||||
@@ -118,9 +118,9 @@ coder:
|
||||
```
|
||||
|
||||
You can view our
|
||||
[Helm README](https://github.com/coder/coder/blob/main/helm/coder#readme) for
|
||||
[Helm README](../../helm/coder#readme) for
|
||||
details on the values that are available, or you can view the
|
||||
[values.yaml](https://github.com/coder/coder/blob/main/helm/coder/values.yaml)
|
||||
[values.yaml](../../helm/coder/values.yaml)
|
||||
file directly.
|
||||
|
||||
We support two release channels: mainline and stable - read the
|
||||
|
||||
@@ -127,8 +127,8 @@ kubectl create secret generic coder-db-url -n coder \
|
||||
# - my-tls-secret-name
|
||||
```
|
||||
|
||||
For available configuration options, refer to the [Helm chart documentation](https://github.com/coder/coder/blob/main/helm#readme)
|
||||
or [values.yaml file](https://github.com/coder/coder/blob/main/helm/coder/values.yaml).
|
||||
For available configuration options, refer to the [Helm chart documentation](../../helm#readme)
|
||||
or [values.yaml file](../../helm/coder/values.yaml).
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
@@ -172,7 +172,7 @@ If an upgrade gets stuck in a restart loop due to database locks:
|
||||
1. **Ensure image version:** Confirm the Deployment image is set to the
|
||||
appropriate version (old or new, depending on the database migration state
|
||||
found in step 3). Match your tag in the
|
||||
[migrations directory](https://github.com/coder/coder/tree/main/coderd/database/migrations)
|
||||
[migrations directory](../../coderd/database/migrations)
|
||||
to the value in the `schema_migrations` output.
|
||||
|
||||
1. **Resume the upgrade:** Follow the
|
||||
|
||||
@@ -100,7 +100,7 @@ workloads, so the cluster should be deployed as such, without production-level
|
||||
configurations.
|
||||
|
||||
Adjust the CPU and memory values as shown in
|
||||
[Helm provisioner values.yaml](https://github.com/coder/coder/blob/main/helm/provisioner/values.yaml#L134-L141):
|
||||
[Helm provisioner values.yaml](../../../helm/provisioner/values.yaml#L134-L141):
|
||||
|
||||
```yaml
|
||||
…
|
||||
|
||||
Reference in New Issue
Block a user