Resources

Four resource types exist purely to be constructed and then referenced by other objects — none of them have real commands of their own except Directory, whose real commands (index/lint/package/dependency management, plus purging its contents or creating a fresh one) are documented alongside it here, and File, which can likewise be created fresh with real content instead of only referencing an existing one. See BDD conventions for how <Resource> substitution works in general — the same <...> mechanism also resolves Helm Release/HTTP Endpoint/HTTPS Endpoint references to real objects, not just these four.

Directory

ShortFull

Given Directory "<ChartsDirectory>" at "./charts"

Given Directory known as "<ChartsDirectory>":
  | PROPERTY | VALUE    |
  | path     | ./charts |

Registers a local filesystem path, checked to really exist at construction time. Directory has exactly one real field (path), so the oneline form covers every real construction; the table form still exists underneath, and is what -full.feature files use throughout — -short.feature files instead reach for a real Payload accumulator for the negative-path tests that need an unknown/missing field:

ShortFull

Given "<BadDirectoryPayload>" field "xxx" is "./charts"
When I attempt to define Directory known as "<BadDirectory>" using "<BadDirectoryPayload>"
Then it should have failed with 'Directory has no field "xxx"'

When I attempt to define Directory known as "<BadDirectory>":
  | PROPERTY | VALUE    |
  | xxx      | ./charts |
Then it should have failed with 'Directory has no field "xxx"'

Referenced by a Helm Chart:

Given Directory "<NginxChartDirectory>" at "./charts/test-nginx"
And Helm Chart "<LocalNginxHelmChart>" in "<NginxChartDirectory>"

See Helm: Index/Lint/Package/Manage Dependencies for the real helm-backed commands this resource feeds — this page only covers construction and the one command below that isn't a helm invocation.

Purge a Directory

When I purge Directory known as "<Resource>"

Empties the directory's contents on disk (except .gitkeep). A pure filesystem operation, no helm invocation — used to restore a genuine "nothing downloaded yet" precondition before a dependency scenario.

When I purge Directory known as "<DownloadsDirectory>"

Create a fresh Directory

When I create Directory known as "<Resource>" at "<path>"

A real mkdir -p, then registers the alias — the counterpart to purging: that assumes the directory already exists, this makes a genuinely fresh one (e.g. somewhere to generate an SSH keypair or a self-signed certificate into). Idempotent — re-running it against the same path is a no-op if it's already there. The <path> argument is soft-substituted (captured-value substitution), so a worker-scoped path can embed a captured value (e.g. <WorkerId> under cucumber-js's own --parallel) — a literal path with no <...> token is unaffected.

When I create Directory known as "<KeypairDirectory>" at ".cache/ssh"

File

ShortFull

Given File "<NginxChartFile>" at "./charts/test-nginx-0.1.0.tgz"

Given File known as "<NginxChartFile>":
  | PROPERTY | VALUE                          |
  | path     | ./charts/test-nginx-0.1.0.tgz  |

A local file path, checked to really exist at construction time — typically a packaged chart archive (.tgz) used as a Chart's local-archive source. File has exactly one real field (path); the table form is what -full.feature stays with throughout, and the negative-path tests use the same Payload accumulator shape as Directory above:

ShortFull

Given "<BadFilePayload>" field "xxx" is "./charts/test-nginx-0.1.0.tgz"
When I attempt to define File known as "<BadFile>" using "<BadFilePayload>"
Then it should have failed with 'File has no field "xxx"'

When I attempt to define File known as "<BadFile>":
  | PROPERTY | VALUE                          |
  | xxx      | ./charts/test-nginx-0.1.0.tgz  |
Then it should have failed with 'File has no field "xxx"'

Referenced by a Helm Chart:

Given File "<NginxChartFile>" at "./charts/test-nginx-0.1.0.tgz"
And Helm Chart "<LocalArchiveNginxHelmChart>" in "<NginxChartFile>"

A chart sourced from a local archive instead of a directory.

Create a fresh File

When I create File known as "<Resource>" at "<path>" with:
  """
  <real content>
  """

A real mkdir -p of the parent directory followed by a real write, then registers the alias — for a scenario that needs a real file with known content on disk (a settings file, a generated trust-store config) rather than one already committed to the repo. Both <path> (soft-substituted, same as Directory's create action above) and content (strictly substituted) run through captured-value substitution, so either can embed a previously captured value (e.g. a dynamic namespace in a generated buildkitd.toml trust rule, or a worker-scoped path segment under --parallel).

When I create File known as "<SettingsFile>" at ".cache/settings.json" with:
  """
  {"buildkit": {"endpoint": "tcp://buildkit:1234"}}
  """

URL

ShortFull

Given URL "<BitnamiRepoUrl>" at "https://charts.bitnami.com/bitnami"

Given URL known as "<BitnamiRepoUrl>":
  | PROPERTY | VALUE                               |
  | value    | https://charts.bitnami.com/bitnami  |

An http(s):// URL, validated as well-formed at construction time. Used as a Chart's url source or a Repository's url. URL has exactly one real field (value); negative-path tests use the same Payload accumulator shape:

ShortFull

Given "<MalformedUrlPayload>" field "value" is "not-a-url"
When I attempt to define URL known as "<MalformedUrl>" using "<MalformedUrlPayload>"
Then it should have failed with 'URL is not well-formed'

When I attempt to define URL known as "<MalformedUrl>":
  | PROPERTY | VALUE     |
  | value    | not-a-url |
Then it should have failed with 'URL is not well-formed'

Referenced by a Helm Repo:

Given URL "<BitnamiRepoUrl>" at "https://charts.bitnami.com/bitnami"
And Helm Repo "<BitnamiHelmRepo>" named "bitnami" at "<BitnamiRepoUrl>"

The same URL resource feeding a Repository.

OCI Artifact

ShortFull

Given OCI Artifact "<NginxOciArtifact>" at "oci://registry-1.docker.io/bitnamicharts/nginx"

Given OCI Artifact known as "<NginxOciArtifact>":
  | PROPERTY | VALUE                                          |
  | ref      | oci://registry-1.docker.io/bitnamicharts/nginx |

An OCI registry reference (oci://...), validated for the correct scheme at construction time. Used as a Chart's oci source. OCI Artifact has exactly one real field (ref); negative-path tests use the same Payload accumulator shape:

ShortFull

Given "<NotOciPayload>" field "ref" is "https://example.com/charts"
When I attempt to define OCI Artifact known as "<NotOci>" using "<NotOciPayload>"
Then it should have failed with 'OCIArtifact ref must start with "oci://"'

When I attempt to define OCI Artifact known as "<NotOci>":
  | PROPERTY | VALUE                       |
  | ref      | https://example.com/charts  |
Then it should have failed with 'OCIArtifact ref must start with "oci://"'

Referenced by a Helm Chart:

Given OCI Artifact "<NginxOciArtifact>" at "oci://registry-1.docker.io/bitnamicharts/nginx"
And Helm Chart "<OciNginxHelmChart>" in "<NginxOciArtifact>"