Addresses https://github.com/coder/nexus/issues/116.
## Core Concept
Send one final telemetry report after the user disables telemetry with
the message that the telemetry was disabled. No other information about
the deployment is sent in this report.
This final report is submitted only if the deployment ever had telemetry
on.
## Changes
1. Refactored how our telemetry is initialized.
2. Introduced the `TelemetryEnabled` telemetry item, which allows to
decide whether a final report should be sent.
3. Added the `RecordTelemetryStatus` telemetry method, which decides
whether a final report should be sent and updates the telemetry item.
4. Added tests to ensure the implementation is correct.
Addresses https://github.com/coder/nexus/issues/175.
## Changes
- Adds the `telemetry_items` database table. It's a key value store for
telemetry events that don't fit any other database tables.
- Adds a telemetry report when HTML is served for the first time in
`site.go`.
Addresses https://github.com/coder/internal/issues/317.
## Changes
Requirements are quoted below:
> how many orgs does deployment have
Adds the Organization entity to telemetry.
> ensuring resources are associated with orgs
All resources that reference an org already report the org id to
telemetry. Adds a test to check that.
> whether org sync is configured
Adds the `IDPOrgSync` boolean field to the Deployment entity.
## Implementation of the org sync check
While there's an `OrganizationSyncEnabled` method on the IDPSync
interface, I decided not to use it directly and implemented a
counterpart just for telemetry purposes. It's a compromise I'm not happy
about, but I found that it's a simpler approach than the alternative.
There are multiple reasons:
1. The telemetry package cannot statically access the IDPSync interface
due to a circular import.
2. We can't dynamically pass a reference to the
`OrganizationSyncEnabled` function at the time of instantiating the
telemetry object, because our server initialization logic depends on the
telemetry object being created before the IDPSync object.
3. If we circumvent that problem by passing the reference as an
initially empty pointer, initializing telemetry, then IDPSync, then
updating the pointer to point to `OrganizationSyncEnabled`, we have to
refactor the initialization logic of the telemetry object itself to
avoid a race condition where the first telemetry report is performed
without a valid reference.
I actually implemented that approach in
https://github.com/coder/coder/pull/16307, but realized I'm unable to
fully test it. It changed the initialization order in the server
command, and I wanted to test our CLI with Org Sync configured with a
premium license. As far as I'm aware, we don't have the tooling to do
that. I couldn't figure out a way to start the CLI with a mock license,
and I didn't want to go down further into the refactoring rabbit hole.
So I decided that reimplementing the org sync checking logic is simpler.
Another PR to address https://github.com/coder/coder/issues/15109.
Changes:
- Introduces the `--ephemeral` flag, which changes the Coder config
directory to a temporary location. The config directory is where the
built-in PostgreSQL stores its data, so using a new one results in a
deployment with a fresh state.
The `--ephemeral` flag is set to replace the `--in-memory` flag once the
in-memory database is removed.
We're seeing test-go-pg flakes on macOS in CI. We've had the same
problem on Windows, and reducing test parallelism in
https://github.com/coder/coder/pull/16090 seemed to help. This PR makes
the same change on macOS.
This PR:
- Reduces test parallelism on Windows in CI
- Unifies wait intervals on Windows with Linux and macOS. Previously we
had custom intervals for Windows to reduce test flakiness on smaller CI
workers, but we don't run tests on small CI workers anymore. Due to how
our CI file is defined, forks run tests on small CI machines, but I'm
not sure if the different intervals actually help or whether that's a
heuristic that happened to fix issues on a particular day and was it
ever reevaluated. I propose we make the change and if someone complains,
revert it.
In particular, reduced test parallelism seems to actually help: I was
able to run Windows tests 5 times in a row without flakes. Not sure if
that's going to fix the problem long term, but it seems worth trying.
Another PR to address https://github.com/coder/coder/issues/15109.
- adds the DisableForeignKeysAndTriggers utility, which simplifies
converting tests from in-mem to postgres
- converts the dbauthz test suite to pass on both the in-mem db and
Postgres
Addresses https://github.com/coder/coder/issues/15663.
This PR saves the entire coder home directory in a Docker volume to make
the dev tunnel URL persistent across container restarts.
I initially wanted to persist only the config directory, but Docker
Compose cannot set permissions on a named volume unless the directory
it’s mounted on already exists within the container. The
`/home/coder/.config` directory, however, is not created by default in
the Dockerfile. When I attempt to mount it, [Docker creates it with root
permissions](https://github.com/moby/moby/issues/2259#issue-21132999),
and Coder cannot write to it. I encounter the following error:
```
coder-1 | Started HTTP listener at http://0.0.0.0:7080
coder-1 | Opening tunnel so workspaces can connect to your deployment. For production scenarios, specify an external access URL
coder-1 | Encountered an error running "coder server", see "coder server --help" for more information
coder-1 | error: create tunnel: read or generate config: get config path: mkdirall config dir "/home/coder/.config/coderv2": mkdir /home/coder/.config/coderv2: permission denied
```
Creating the directory in the Dockerfile would resolve the issue for new
images but would break `docker-compose.yml` for all existing Coder
images. Mounting the entire home directory avoids this problem, but it
makes it less clear to admins which files need to be persisted. It’s a
trade-off - I believe keeping Docker Compose backwards-compatible is
more important, and I hope the added comment clarifies the purpose of
the volume for new users.
This PR is the second in a series aimed at closing
https://github.com/coder/coder/issues/15109.
## Changes
- adds `scripts/embedded-pg/main.go`, which can start a native Postgres
database. This is used to set up PG on Windows and macOS, as these
platforms don't support Docker in Github Actions.
- runs the `test-go-pg` job on macOS and Windows too
- adds the `test-go-race-go` job, which runs race tests with Postgres on
Linux
Addresses https://github.com/coder/nexus/issues/99.
Changes:
- Save the id of the built-in example template used to create a template
version in the database
- Include the example id in telemetry
Addresses https://github.com/coder/nexus/issues/35.
This PR:
- Adds a `workspace_modules` table to track modules used by the
Terraform provisioner in provisioner jobs.
- Adds a `module_path` column to the `workspace_resources` table,
allowing to identify which module a resource originates from.
- Starts pushing this new information into telemetry.
For the person reviewing this PR, do not fret about the 1,500 new lines
- ~1,000 of them are auto-generated.
This PR is the first in a series aimed at closing
[#15109](https://github.com/coder/coder/issues/15109).
### Changes
- **Template Database Creation:**
`dbtestutil.Open` now has the ability to create a template database if
none is provided via `DB_FROM`. The template database’s name is derived
from a hash of the migration files, ensuring that it can be reused
across tests and is automatically updated whenever migrations change.
- **Optimized Database Handling:**
Previously, `dbtestutil.Open` would spin up a new container for each
test when `DB_FROM` was unset. Now, it first checks for an active
PostgreSQL instance on `localhost:5432`. If none is found, it creates a
single container that remains available for subsequent tests,
eliminating repeated container startups.
These changes address the long individual test times (10+ seconds)
reported by some users, likely due to the time Docker took to start and
complete migrations.