Terrateam on ¬ just serendipity 🍀

terrateam: plan from drift issues

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 24 Aug 2026 18:38:39 +0200

♠ Problem statement: Terrateam opens drift reports as GitHub issues, but terrateam plan only works on pull requests.

The distinction is explicit in Terrateam’s issue comment handler:

{ primary = Primary.{ number = pull_request_id; pull_request = Some _; _ }; _ };

| Gw.Issue_comment_event.Issue_comment_created _ ->
    Logs.debug (fun m -> m "%s : NOOP : ISSUE_COMMENT_CREATED" request_id);
    Prmths.Counter.inc_one (Metrics.comment_events_total "noop");
    Abbs_future_combinators.return_ok ()

Calling the repository workflow directly was not an option either. Its work token comes from the Terrateam backend.

So I kept Terrateam in charge and gave it the pull request it expects. A GitHub Actions relay checks that the source is an open Terrateam drift issue and that the commenter has repository write access. It then puts a comment-only Terraform file in each selected drift directory:

markers = [
    InputGitTreeElement(
        path=f"{directory}/terrateam_issue_relay.tf",
        mode="100644",
        type="blob",
        content=f"# Terrateam plan relay for drift issue #{issue_number}, comment {comment_id}.\n",
    )
    for directory in directories
]

That path change gives Terrateam a real dirspace without changing infrastructure. The relay opens a temporary draft PR and posts the original command on it:

pull = repo.create_pull(
    base=repo.default_branch,
    head=branch,
    title=f"Terrateam plan relay for drift issue #{issue_number}",
    body=relay_body(issue_number, comment_id, event["comment"]["html_url"]),
    draft=True,
)
pull.as_issue().create_comment(command)

Terrateam uses its normal locks, hooks, credentials, and batching. Another workflow copies its comments back to the drift issue. apply remains unsupported: an issue has no PR approval or review intent.

The live test planned the requested directory and returned the result:

## Plans :thumbsup:

## Terrateam Plan Output :thumbsup:

**Plan: 0 to add, 8 to change, 0 to destroy**

The temporary PR ended where it should:

% gh pr view 6687 --json number,state,headRefName,title
{"headRefName":"bot/terrateam-issue-relay/6663-5398113346","number":6687,"state":"CLOSED","title":"Terrateam plan relay for drift issue #6663"}

% ./ci/run_python_tests.sh ci/terrateam_issue_relay
collected 19 items
tests/test_relay.py ...................                                  [100%]
============================== 19 passed in 1.45s ==============================

A scheduled job deletes inactive relay branches after 30 hours. Terrateam still owns plan execution; the relay only translates the issue command into its existing PR protocol.

🤖 Drafted with /bloggify. ∎

— § —

Reply via email

#bloggify #dev #terraform #terrateam

★ Justfile with checks

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 27 Apr 2026 10:42:00 +0200

♠ Previously.

I love just to manage a small collection of related scripts within a given codebase. An example in our Terraform codebase¹:

% just check-{hit TAB for completion}
completing values
check-aws-config         -- Validate AWS profiles in ~/.aws/config
check-aws-provider-tags  -- Check AWS provider default_tags configuration
check-backend-locking    -- Verify S3 backends have use_lockfile = true
check-import-blocks      -- Check for Terraform import blocks
check-lockfiles          -- Check that all projects have lockfiles
check-moved-blocks       -- Check for Terraform moved blocks
check-secret-accounts    -- Check expected_account_id in terraform-secrets
check-secrets-tf         -- Validate secrets.tf file structure
check-shared-values      -- Check for hardcoded values that duplicate shared modules
check-stacks             -- Verify garden projects have correct stack tags
check-terraform-version  -- Validate .terraform-version format
check-terrateam-tags     -- Verify projects are tagged in Terrateam config
check-tfdocs             -- Check that all README.md have TF_DOCS blocks

Adopting a common prefix (check-) improves their discoverability.

There’s no need to rely on interactivity to take advantage of just:

% just --list
Available recipes:
    default                                            # Show categorized help for available commands
    help                                               # Display categorized help for available commands

[...]

    [terraform]
    apply module_path=invocation_directory() *args=""  # Run terraform apply
    clean module_path=invocation_directory()           # Remove .terraform artifacts
    destroy module_path *args=""                       # Run terraform destroy
    fmt module_path=invocation_directory() *args=""    # Format terraform files
    import module_path *args=""                        # Run terraform import
    init module_path=invocation_directory() *args=""   # Initialize terraform with backend config
    output module_path=invocation_directory() *args="" # Show terraform outputs
    plan module_path=invocation_directory() *args=""   # Run terraform plan
    providers-lock module_path=invocation_directory() *args="" # Lock providers for multiple platforms
    refresh module_path=invocation_directory() *args="" # Run terraform refresh
    show module_path=invocation_directory() *args=""   # Show terraform state or plan
    stack-apply *args=""                               # Apply projects in Terrateam stack order (--dry-run for preview)
    stack-plan *args=""                                # Plan projects in Terrateam stack order
    state module_path=invocation_directory() *args=""  # Run terraform state commands
    test module_path=invocation_directory() *args=""   # Run terraform tests
    unlock *args=""                                    # Force unlock state lock (auto-detects lock ID) [alias: force-unlock]
    upgrade module_path=invocation_directory() *args="" # Upgrade providers to latest versions
    validate module_path=invocation_directory() *args="" # Validate terraform configuration

[...]

Justfile groups enhance --list by grouping(!) entries together.

This is what a typical entry looks like:

[doc('Validate AWS profiles in ~/.aws/config')]
[group('checks')]
check-aws-config:
    @./ci/check_aws_config.sh

just is just (pun intended) a glue for various shell and Python scripts in ci/. ∎

I wrote all of these. ↩︎

— § —

Reply via email

#bestof #dev #serenity #terrateam

★ Gimme subagents

serendipity@perrotta.dev (Thiago Perrotta) — Mon, 23 Feb 2026 10:57:55 +0100

♠ Scenario: we’re test-driving the adoption of a Terrateam feature called stacks. The specifics aren’t relevant here.

In a typical agentic LLM session with Claude Code¹, the feature was drafted (planned) and then subsequently implemented.

Following that comes the important part: testing! As part of the testing process I tend to resonate with Thorsten Ball:

Most of the time, when I work with Amp, I know in advance (a) what I want the resulting code to do and (b) how I will test that it does exactly that.

Once Amp declares it’s done writing code, I test. And what I mean is that I “test”, in every possible meaning of the word. The goal is to make sure the code actually does what it’s supposed to do. That can mean: asking Amp to run the unit tests, asking it to manually test in a browser, asking it to run a command, or check the data in the database, run the curl. With every tool I have — Amp, code, my hands and eyes — I test the happy path, the teary path, the edge cases. I make sure to test with existing data, no data, real data, fake data. I think about what might be different in production and how I could test that. Sometimes I ask Amp itself how I can manually verify what it just did and ask it to walk me through the testing.

How exactly I test very much depends on what I’m testing. Not all functionality and code have the same blast radius. Some sit at the heart of a system, some are peripheral. Adjust accordingly.

But once I’ve tested something and compared how it works with my mental model of how it’s supposed to work, then the code, I find, becomes less important.

Yes, I’ll do spot-checks to make sure it isn’t completely insane (less and less of a problem with these new models). I also go through my mental list of always-check-these things like (a) where and how is the data stored (b) will this box us in and prevent future changes (c) security (d) does it touch functionality I hadn’t considered. Sometimes that can take a while, other times there’s barely anything to do.

…hence I surely prompt the LLM to suggest me how to test the feature:

⏺ Here's how to test the stacks feature:

  1. Validate the config syntax

  just check-terrateam-tags

  This confirms all projects referenced in .terrateam/config.yml have valid tags, including the new corp-network-check tags.

  2. Verify tag assignments are correct

  Check that the right projects land in each stack:

  # Foundation layer projects
  just list-projects-by-tag network
  just list-projects-by-tag terraform-secrets
  just list-projects-by-tag atlas

  # Compute layer projects
  just list-projects-by-tag eks
  just list-projects-by-tag corp-network-check

  # Services layer (future)
  just list-projects-by-tag service-identity

  Confirm that every cluster project falls into exactly one of the three stacks.

  3. Validate the config file itself

  just validate-terrateam-config   # if this recipe exists
  # or simply:
  yamllint .terrateam/config.yml   # basic YAML syntax check

  4. Test on a real PR (the real test)

  Stacks are a Terrateam server-side feature — the ordering logic runs in Terrateam's CI, not locally. The only real end-to-end test is:

  [...]

For the sake of preserving the context window of my current session, I employ the following technique:

❯ 1) OK (in a subagent)
  2) OK (in a subagent, in parallel)
  3) OK (in a subagent, in parallel)

  let's do these first. Prompt me before going to 4

⏺ 3 agents finished (ctrl+o to expand)
   ├─ Bash (Check terrateam tags validation) · 1 tool use · 13.3k tokens
   │  ⎿  Done
   ├─ Task (Verify tag assignments per stack) · 17 tool uses · 32.3k tokens
   │  ⎿  Done
   └─ Bash (Validate terrateam config YAML) · 7 tool uses · 16.5k tokens
      ⎿  Done

And that works exactly as you would expect it to.

⏺ All three checks passed:

  1. Tag validation (just check-terrateam-tags)

  All {redacted – number of projects} standalone projects are properly tagged.

  2. Stack tag assignment verification

  ┌─────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
  │                  Check                  │                                                    Result                                                    │
  ├─────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Cluster projects missing from all stacks│ None — all {redacted – number of projects} cluster projects are covered                                      │
  ├─────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Cluster projects in multiple stacks     │ None — tag sets are disjoint                                                                                 │
  ├─────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Non-cluster projects in stacks          │ 10 projects (6 terraform-secrets, 1 opsgenie, 3 atlas) — all in cluster-foundation, expected/harmless per ADR│
  ├─────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
  │ Placeholder tags (not yet in use)       │ deploy, rds, service-identity — cluster-services stack is currently empty                                    │
  └─────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

  3. Config validation

  - yamllint: passed (zero warnings/errors)
  - just check: all checks passed (AWS profiles, terrateam tags, AWS provider tags)

  Everything looks good locally. Ready for step 4 (push branch, open PR, test Terrateam's stack ordering on a real PR) whenever you want to proceed.

In prose: consider using subagents (i) to preserve your context window, and (ii) to speed up testing by running them in parallel.

One disadvantage: I’d avoid using subagents in this manner whenever the testing procedures aren’t clearly well-defined and scoped (for example, whenever they are ambiguous or uncertain). Why? Because I’d rather have full control in these complex scenarios, by having the ability to manually steer the LLM in real-time. With subagents you have limited ability to do so.

Last but not least: subagents are not an exclusive feature of Claude Code:

Pi has a couple of extensions that add subagents capabilities to it. Example (untested)
And so does OpenCode.
I am a bit surprised to find out that Codex does not support them yet. Or does it?

Should I stop linking to their website? At this point, every Software Engineer has heard of Claude Code at least once, right? ↩︎

∎

— § —

Reply via email

#ai #bestof #claude #dev #terrateam

.terraform-version

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 24 Oct 2025 15:12:18 +0200

♠ .terraform-version at the root of a git repository is recognized by various tools:

You would expect the hashicorp/setup-terraform github action would also recognize it out-of-the-box, but it does not. We can address this gap by reading it manually:

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8 # v5.0.0
        with:
          persist-credentials: false

      - name: Read Terraform version
        id: terraform-version
        run: echo "version=$(cat .terraform-version)" >> "$GITHUB_OUTPUT"

      - uses: hashicorp/setup-terraform@b9cd54a3c349d3f38e8881555d616ced269862dd # v3.1.2
        with:
          terraform_version: ${{ steps.terraform-version.outputs.version }}

There’s a feature request for it. ∎

— § —

Reply via email

#dev #terraform #terrateam