Skip to content

dagger do should check for a valid plan #1711

@shykes

Description

@shykes

Problem

Currently, dagger do (and its 0.1 predecessor dagger up) does not check that a plan is valid before running it. It delegates this task to the CUE loader, which in turn requires the developer to explicitly apply a top-level definition, like so:

import (
  "dagger.io/dagger"
)

dagger.#Plan & {
  // Plan configuration goes here
  ...
}

This is valid CUE, and we should support it. But it does not solve several problems caused by the absence of an explicit validity check:

  1. Developers can shoot themselves in the foot by declaring fields outside the dagger.#Plan definition. For example:
dagger.#Plan & {
  ...
}
// Typo in a field name. Will not be caught.
clients: { ... }
// Still using a deprecated field name. Will not be caught.
inputs: { ... }

This is normal CUE behavior, but may not be immediately obvious to all developers.

  1. If a plan spans multiple files, the top-level incantation must be repeated in each file. This is verbose (which makes DX incrementally worse) and also increases risks of mistakes.

  2. It closes the door to denying top-level configuration fields. We're not yet certain which pattern is best: allow unrelated top-level fields to co-exist with the plan? Or forbid it? In doubt, we should go for the most reversible choice, which is to deny it (we can always allow it later with no breakage, but the opposite is not true). This would be a side effect of checking for valid plans.

Solution

Modify dagger do to explicitly check for a valid plan by unifying it against dagger.#Plan.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions