Possible to handle CLI options like `-no-color`, `-json`, `-target`?

[Infinoid]

I noticed that initiating a tofu plan or tofu apply from the CLI seems to ignore arguments that affect planning and output generation. I can't apply (or destroy) a targeted subset of resources, and I can't request machine-readable plan output (for parsing out existing resources I need to import, for example).

Is that something the cloud backend protocol allows for? Are these command-line arguments sent to OTF, or does the command line tool just drop them on the floor?

Example: when I run tofu plan -no-color and log the result to a file, the logs look like:

Running plan in cloud backend. Output will stream here. Pressing Ctrl-C
will stop streaming the logs, but will not stop the plan running remotely.

Preparing the remote plan...

To view this run in a browser, visit:
https://otf.host.name/app/org/workspace/runs/run-32tfjJvKavJJ5rko

Waiting for the plan to start...


ESC[0mESC[1mInitializing the backend...ESC[0m
ESC[0mESC[1mInitializing modules...ESC[0m

ESC[0mESC[1mInitializing provider plugins...ESC[0m

Without -no-color, the first lines ("Running plan in cloud backend") are colored yellow. The flag stops that, but has no effect on the plan output sent back by OTF.

[leg100]

Can confirm behaviour with -no-color.

Can also confirm that HCP Terraform does turn off color when setting -no-color.

Looking on the wire, the difference is that HCP sends back logs in the machine readable UI format. Presumably the client, whether it's tofu or terraform, then decides whether to color code it or not according to whether the flag has been set.

Implementing this would be a big task. It would mean instructing the tofu invoked on the OTF server to spew machine readable formatted output. That would then be relayed to the client. That bit is simple. But then the output also needs to be relayed via the OTF UI. The output would then need to be rendered accordingly, translating it back into the conventional format. That's a bit of work.

Saying that, the code to do that will already exist somewhere in the tofu source code.

And there are advantages to the machine readable output. Because it is structured, OTF can determine things like the number of applied resources in a structured manner, rather than parsing it out of the conventional logs as it does now.

JSON: Same as above. This'll only work with machine readable output.

Targeting: that is something that is sent on the wire. OTF would appear not to do anything with the parameter. That's an easy fix. (You might want to have a look at implementing this, check out the target-addrs parameter on the create run endpoint).

[Infinoid]

You might want to have a look at implementing this

Thanks, I may. I do stumble over this occasionally, and the more it bugs me, the more likely I am to try fixing it.

The discussion of the wire protocol is very helpful too, thanks. I can see why it would be a big task.