这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@walteh
Copy link
Owner

@walteh walteh commented Aug 5, 2025

Summary

  • support block syntax and ordered deps in HCL loader
  • introduce native HCL runtime with shell and task built-ins
  • add integration and runtime tests for HCL features

Testing

  • go test ./...

Prompt

🗂️ Story Card – “Native-HCL Runtime, Blocks-only Vars/Env, Array Deps, Built-ins, E2E Test”

Hand this directly to Codex. It contains requirements, expectations, and acceptance tests only — no code skeletons, no file-layout mandates (except for the single test-data directory).


📌 Goal

Deliver full HCL Taskfile support such that:

  1. Block syntax only for variables and environment:

    vars { … }
    env  { … }

    Both root-level and inside each task block.

  2. Dependencies are expressed as an ordered list (array) – not a map:

    deps = [
      task("build"),                 # simple reference
      task("lint", {MODE = "fast"})  # with param vars
    ]

    – The list order is respected during execution.
    – Each entry is either a bare task reference or task(name, vars) expression.

  3. All interpolation uses native HCL expressions:

    echo "${upper(vars.FOO)} - ${env.PATH}"

    – Variable access is always vars.X or env.Y.

  4. Runtime HCL evaluation provides built-in functions:

    Function Purpose & Expected Behaviour
    sh(cmd) Run /bin/sh -c cmd, return trimmed stdout
    bash(cmd) Run /bin/bash -c cmd
    zsh(cmd) Run /bin/zsh -c cmd
    task(name, vars?) Execute another task synchronously, optionally overriding its vars; returns that task’s combined stdout
  5. **Go-template ({{ }}) syntax is invalid inside HCL files.


🛠️ Functional Requirements & Expectations

# Area Requirement / Scenario Expected Outcome
1 Parsing Root and task blocks may contain vars {} and env {} only (attribute form vars = {} must raise parse error). HCL loader returns a diagnostics error pinpointing incorrect syntax.
2 Parsing deps attribute must decode as ordered list of HCL expressions. Internal representation preserves list order; non-list structures are rejected.
3 Evaluation At runtime, build an EvalContext exposing vars and env objects and the built-ins above. Any expression ${vars.FOO} or upper(vars.FOO) evaluates to the current value.
4 Built-in sh sh("echo hi") returns "hi" (newline trimmed). Non-zero exit → task fails with clear message. Unit test asserts "hi"; failure path triggers task error.
5 Built-in task task("build") runs the task before returning. Returned string equals that task’s combined stdout. Overrides passed via second arg apply only to that invocation. Integration test checks build output present, var override honoured.
6 Dep ordering Given deps = [task("one"), task("two")], Task “one” executes before “two”. Integration test looks for markers “ONE-DONE” then “TWO-DONE” in output order.
7 Reference consistency Inside any expression, vars.X and env.Y are the only legal references. Accessing FOO or .FOO directly must fail eval. Unit test: expression ${FOO} ➜ evaluation error.
8 Cross-format isolation YAML Taskfiles continue to use Go templates; HCL Taskfiles never attempt Go-template expansion. Existing YAML test suite passes unchanged; new unit test confirms {{ .FOO }} in HCL raises parse error.

🧪 Required Tests

Location: create internal/testdata/HCLE2ETest/ (or analogous) that is committed with the repo.

  1. Taskfile.hcl in HCLE2ETest – must demonstrate:

    • Root vars { ORIGINAL = "foo" }

    • Root env { PATH_COPY = env("PATH") }

    • Task build:

      vars { VERSION = sh("echo 1.2.3") }
      cmds = ["echo BUILD:$${vars.VERSION}", "echo ONE-DONE"]
    • Task lint with var override via task():

      cmds = ["echo LINT MODE $${vars.MODE}", "echo TWO-DONE"]
    • Task all:

      deps = [
        task("build"),
        task("lint", {MODE = "fast"})
      ]
      cmds = [
        "echo FINAL $${vars.ORIGINAL}",
        "echo PATH=$${env.PATH_COPY}"
      ]
  2. Integration test (TestHCLE2E):

    • Run task -t testdata/HCLE2ETest/Taskfile.hcl all.

    • Assertions (order matters):

      1. Contains BUILD:1.2.3
      2. Contains ONE-DONE before TWO-DONE
      3. Contains LINT MODE fast
      4. Contains FINAL foo
      5. Contains PATH= plus a non-empty value
  3. Unit tests (examples, not code):

    • TestBlockSyntaxEnforced: file using vars = {} returns parse error.
    • TestShFunctionSuccess / TestShFunctionFail.
    • TestTaskFunctionStdoutCapture.
    • TestInvalidReference: ${FOO} raises evaluation error.
    • TestTemplateSyntaxRejected: {{ .FOO }} in HCL raises parse error.

📎 General Guidance for Codex

  • Focus on satisfying behaviour & tests; internal file structure is up to you.
  • Preserve existing YAML behaviour.
  • Return informative diagnostics on parse/eval errors.
  • Ensure go test ./... passes and prints the HCLE2ETest markers in correct order.

No further implementation details or file names are prescribed beyond the test-data directory above.


https://chatgpt.com/codex/tasks/task_e_68921dd450d08330945d7ec60c6a40aa

@walteh walteh merged commit 53c52b7 into codex/hcl Aug 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants