Module project 

The project copied into the machines, without what .isoloomignore leaves out: its rules (ignore, the run manifest’s: the runner’s project.archive follows them too), and the same rules in the Terraform outputs, read when Terraform runs, exactly as the Vagrantfiles read them (vagrant_project.rb), so every target leaves out the same files.

• Proxmox writes the project’s files through cloud-init: local.project_paths, the files that go (not version control, the tools’ state, or Isoloom’s outputs).

• The cloud modules archive the project on the host with tar, which walks it itself (symbolic links kept as links): local.project_ignored, the files that don’t go, is its exclusion list (-X, a file next to the module: local_file.isoloom_project). Each entry starts with the project folder’s name (the archive’s top folder, stripped when unpacked), since bsdtar (macOS, Windows) matches exclusions at any depth. A Windows machine there, which cloudbase-init sets up, gets the files that go one by one: local.project_paths.

• A module that only makes the machines lists nothing: the runner archives the project and pipes it into each guest over SSH (Copy::Runner).

A module gets only the lists it reads (lists).

Modules

ignore

.isoloomignore: the project’s paths the machines don’t get when the project is copied into them (Vagrant’s project step, Proxmox’s cloud-init, the cloud modules’ archive, and the runner’s project.archive). Part of the contract: a runner archiving the project leaves out exactly what the generated files do. Gitignore-style, at the project’s root:

Enums

Copy

How a Terraform module copies the project into its machines.

Functions

lists

The lists a module reads, as a fixed HCL fragment: local.project_paths when the rest of the module (module, as written) names it; for an archive, local.project_ignored and tar’s exclusion file, which reads it. Nothing when it reads neither, or when the runner copies the project: a list nothing reads is a declaration Terraform’s linters report.