- As part of merging support for Template RBAC
and user groups a permission check on reading files
was relaxed.
With the addition of admin roles on individual templates, regular
users are now able to push template versions if they have
inherited the 'admin' role for a template. In order to do so
they need to be able to create and read their own files. Since
collisions on hash in the past were ignored, this means that a regular user
who pushes a template version with a file hash that collides with
an existing hash will not be able to read the file (since it belongs to
another user).
This commit fixes the underlying problem which was that
the files table had a primary key on the 'hash' column.
This was not a problem at the time because only template
admins and other users with similar elevated roles were
able to read all files regardless of ownership. To fix this
a new column and primary key 'id' has been introduced to the files
table. The unique constraint has been updated to be hash+created_by.
Tables (provisioner_jobs) that referenced files.hash have been updated
to reference files.id. Relevant API endpoints have also been updated.
With just a few workspaces, the autobuild executor can slow down API
requests every time it runs. This is because we started a long running
transaction and checked all eligible (for autostart) workspaces inside
that transaction. PostgreSQL doesn't know if we're modifying rows and as
such is locking the tables for read operations.
This commit changes the behavior so each workspace is checked in its own
transaction reducing the time the table/rows needs to stay locked.
For now concurrency has been arbitrarily limited to 10 workspaces at a
time, this could be made configurable or adjusted as the need arises.
* fix: Improve `coder server` shutdown procedure
This commit improves the `coder server` shutdown procedure so that all
triggers for shutdown do so in a graceful way without skipping any
steps.
We also improve cancellation and shutdown of services by ensuring
resources are cleaned up at the end.
Notable changes:
- We wrap `cmd.Context()` to allow us to control cancellation better
- We attempt graceful shutdown of the http server (`server.Shutdown`)
because it's less abrupt (compared to `shutdownConns`)
- All exit paths share the same shutdown procedure (except for early
exit)
- `provisionerd`s are now shutdown concurrently instead of one at a
time, the also now get a new context for shutdown because
`cmd.Context()` may be cancelled
- Resources created by `newProvisionerDaemon` are cleaned up
- Lifecycle `Executor` exits its goroutine on context cancellation
Fixes#3245
* add reason field for workspace build
* add the reason field to FE via API
* update BuildReasonMember to BuildReasonInitiator
* add unit tests
* add more unit tests
* add error for unknown transition
* fix lint
* add documentation
* fix unit tests
* fix generated types
* remove nested transaction
* rename migration file
This commit makes the following changes:
- Partially reverts the changes of feat: update workspace deadline when workspace ttl updated #2165, making the deadline of a running workspace build independant of TTL, once started.
- CLI: updating a workspace TTL no longer updates the deadline of the workspace.
- UI: updating a workspace TTL no longer updates the deadline of the workspace.
- Drive-by: API: When creating a workspace, default TTL to min(12 hours, template max_ttl) if not instructed otherwise.
- Drive-by: CLI: list: measure workspace extension correctly (+X in last column) from the time the provisioner job was completed
- Drive-by: WorkspaceSchedule: show timezone of schedule if it is set, defaulting to dayjs guess otherwise.
- Drive-by: WorkspaceScheduleForm: fixed an issue where deleting the "TTL" value in the form would show the text "Your workspace will shut down a few seconds after start".
Removes 5-second wait in autobuild.executor unit tests:
- Adds a write-only channel to Executor and plumbs through to unit tests
- Modifies runOnce to return an executor.RunStats struct and write to statsCh if not nil
* Adds a `bump` command to extend workspace build deadline
* Reduces WARN-level logging spam from autobuild executor
* Modifies `cli/ssh` notifications to read from workspace build deadline and to notify relative time instead (sidestepping the problem of figuring out a user's timezone across multiple OSes)
* Shows workspace extension time in `coder list` output e.g.
```
WORKSPACE TEMPLATE STATUS LAST BUILT OUTDATED AUTOSTART TTL
developer/test1 docker Running 4m false 0 9 * * MON-FRI 15m (+5m)
```
* Adds deadline column to workspace_builds, associated DB/API plumbing
* database: Upon inserting a row into workspace_builds, deadline will
initially be zero.
* autobuild: Executor now checks the Deadline field of the workspace_build
for the purpose of autostop logic.
* coderd: Adds a new route /api/v2/workspaces/:workspace/extend which allows
updating the deadline of the currently active workspace build. The new
deadline must be after the existing deadline, and not the zero time.
* provisionerd: updates workspace_build.deadline upon successful workspace
build completion (equal to now plus workspace TTL, if it exists).
This PR adds a package lifecycle and an Executor implementation that attempts to schedule a build of workspaces with autostart configured.
- lifecycle.Executor takes a chan time.Time in its constructor (e.g. time.Tick(time.Minute))
- Whenever a value is received from this channel, it executes one iteration of looping through the workspaces and triggering lifecycle operations.
- When the context passed to the executor is Done, it exits.
- Only workspaces that meet the following criteria will have a lifecycle operation applied to them:
- Workspace has a valid and non-empty autostart or autostop schedule (either)
- Workspace's last build was successful
- The following transitions will be applied depending on the current workspace state:
- If the workspace is currently running, it will be stopped.
- If the workspace is currently stopped, it will be started.
- Otherwise, nothing will be done.
- Workspace builds will be created with the same parameters and template version as the last successful build (for example, template version)
