Skip to content

chore: Initial database scaffolding#2

Merged
kylecarbs merged 8 commits into
mainfrom
database
Jan 5, 2022
Merged

chore: Initial database scaffolding#2
kylecarbs merged 8 commits into
mainfrom
database

Conversation

@kylecarbs

@kylecarbs kylecarbs commented Jan 4, 2022

Copy link
Copy Markdown
Member

This implements migrations and code generation for interfacing with a PostgreSQL database.

A dependency is added for the "postgres" binary on the host, but that seems like an acceptable requirement considering it's our primary database. We decided Docker was a more reliable and ubiquitous dependency, so we launch a PostgreSQL Docker container instead.

An in-memory database object can be created for simple cross-OS and fast testing.

This implements migrations and code generation for interfacing with a PostgreSQL database.

A dependency is added for the "postgres" binary on the host, but that seems like an acceptable requirement considering it's our primary database.

An in-memory database object can be created for simple cross-OS and fast testing.
@kylecarbs kylecarbs requested a review from bryphe-coder January 4, 2022 15:25
@kylecarbs kylecarbs self-assigned this Jan 4, 2022
Comment thread .github/workflows/coder.yaml Outdated
# Check that go is available
# TODO: Implement actual test run
- run: go version
- run: go test -v ./...

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, our CI is actually doing something now 🎉

if err != nil {
return "", nil, xerrors.Errorf("create pool: %w", err)
}
resource, err := pool.RunWithOptions(&dockertest.RunOptions{

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine to me for now! As we discussed, if Docker is too heavy a dependency... we could look at running psql manually in the future.

I think this approach makes for now, though, since the team is familiar with this approach from coderd. And if we decide Docker is too heavy, there might be other approaches we take (like revisiting a cloud solution...)

@kylecarbs kylecarbs merged commit 025b55f into main Jan 5, 2022
@kylecarbs kylecarbs deleted the database branch January 20, 2022 16:01
bryphe-coder added a commit that referenced this pull request Feb 2, 2022
BrunoQuaresma added a commit that referenced this pull request May 8, 2025
@bpmct bpmct mentioned this pull request Dec 6, 2025
2 tasks
kacpersaw added a commit that referenced this pull request Jan 23, 2026
david-fraley added a commit that referenced this pull request Apr 30, 2026
Two regressions from 8c0a1b2 that fail markdownlint and would block CI:

- MD009: trailing space after the new getting-started link
- MD051: stale '#2-configure-an-llm-provider' fragment in the testing
  section now that the experiment step is removed and Configure an LLM
  provider is step 1

> Coder Agent generated this commit on @david-fraley's behalf.
kylecarbs added a commit that referenced this pull request May 7, 2026
… history

Replaces the previous draft of this PR (a backend workspaces.claimed_at
column plus migration plus SDK plumbing) with a frontend-only
heuristic per Cian's review.

The /agents archive-and-delete molly-guard previously compared
workspace.created_at against chat.created_at to decide whether to
require typing the workspace name. ClaimPrebuiltWorkspace never
updates workspace.created_at, so claimed prebuilds always looked
pre-existing and the dialog misfired.

Build history already records the truth: build #1's initiator is the
prebuilds system user iff the workspace was a prebuild, and build #2
is the claim. Compute that in the resolver and compare its created_at
against the chat. From-scratch workspaces fall through to
workspace.created_at as before.

The prebuilds system user UUID is hardcoded on the frontend; it lives
in coderd/database/constants.go on the backend and has not changed
since the prebuild feature shipped. If it ever moves, both sides have
to move together.

🤖 Generated with the help of Coder Agents.
bpmct added a commit that referenced this pull request May 21, 2026
Co-authored-by: Ben Potter <ben@coder.com>
mafredri added a commit that referenced this pull request May 25, 2026
waitForTaskIdle used time.NewTicker(5s) which delays the first poll
by 5 seconds. Debugger tracing proved the failure mechanism: on slow
CI (Windows), the first poll at 5s sees "working" (idle patch has not
landed due to goroutine scheduling), needs poll #2 at 10s, but the
25s context expires before it fires.

Two changes:

1. Use r.clock.NewTicker (quartz) with time.Nanosecond initial
   interval and Reset(5s) for immediate first poll. Tests inject a
   mock clock via clitest.NewWithClock for deterministic control.
2. Rewrite WaitsForWorkingAppState test with quartz traps
   (NewTicker + TickerReset) for deterministic synchronization
   instead of racing goroutines. Fix PausedDuringWaitForReady
   sync point.

Closes https://linear.app/codercom/issue/DEVEX-381
mafredri added a commit that referenced this pull request May 25, 2026
waitForTaskIdle used time.NewTicker(5s) which delays the first poll
by 5 seconds. Debugger tracing proved the failure mechanism: on slow
CI (Windows), the first poll at 5s sees "working" (idle patch has not
landed due to goroutine scheduling), needs poll #2 at 10s, but the
25s context expires before it fires.

Two changes:

1. Use r.clock.NewTicker (quartz) with time.Nanosecond initial
   interval and Reset(5s) for immediate first poll. Tests inject a
   mock clock via clitest.NewWithClock for deterministic control.
2. Rewrite WaitsForWorkingAppState test with quartz traps
   (NewTicker + TickerReset) for deterministic synchronization
   instead of racing goroutines. Fix PausedDuringWaitForReady
   sync point.

Closes https://linear.app/codercom/issue/DEVEX-381
mafredri added a commit that referenced this pull request May 25, 2026
#25648)

waitForTaskIdle used time.NewTicker(5s) which delays the first poll
by 5 seconds. Debugger tracing proved the failure mechanism: on slow
CI (Windows), the first poll at 5s sees "working" (idle patch has not
landed due to goroutine scheduling), needs poll #2 at 10s, but the
25s context expires before it fires.

Two changes:

1. Use r.clock.NewTicker (quartz) with time.Nanosecond initial
   interval and Reset(5s) for immediate first poll. Tests inject a
   mock clock via clitest.NewWithClock for deterministic control.
2. Rewrite WaitsForWorkingAppState test with quartz traps
   (NewTicker + TickerReset) for deterministic synchronization
   instead of racing goroutines. Fix PausedDuringWaitForReady
   sync point.

Closes DEVEX-381
tracyjohnsonux added a commit that referenced this pull request Jun 3, 2026
…PR tab for demo

Hardcodes 'fix: increase icon sizes for wcag 2.2 compliance' (PR #2
from coder-ux-prototypes) as a second PR tab in the dropdown to
demonstrate multi-PR switching UI. The extra tab reuses the remote
diff content panel.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants