terraform

Commit Graph

Author	SHA1	Message	Date
Martin Atkins	b402fd9d3a	command/views: Remove command-specific runningInAutomation We now have RunningInAutomation has a general concern in views.View, so we no longer need to specify it for each command-specific constructor separately. For this initial change I focused only on changing the exported interface of the views package and let the command-specific views go on having their own unexported fields containing a copy of the flag because it made this change less invasive and I wasn't feeling sure yet about whether we ought to have code within command-specific views directly access the internals of views.View. However, maybe we'll simplify this further in a later commit if we conclude that these copies of the flag are burdensome. The general version of this gets set directly inside the main package, which might at some future point allow us to make the command package itself unaware of this "running in automation" idea and thus reinforce that it's intended as a presentation-only thing rather than as a behavioral thing, but we'll save more invasive refactoring for another day.	5 years ago
Alisdair McDiarmid	8d9a08e3a1	cli: Migrate plan to command views	5 years ago
Alisdair McDiarmid	68558ccd54	backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.	5 years ago

Author

SHA1

Message

Date

Martin Atkins

b402fd9d3a

command/views: Remove command-specific runningInAutomation

We now have RunningInAutomation has a general concern in views.View, so
we no longer need to specify it for each command-specific constructor
separately.

For this initial change I focused only on changing the exported interface
of the views package and let the command-specific views go on having their
own unexported fields containing a copy of the flag because it made this
change less invasive and I wasn't feeling sure yet about whether we
ought to have code within command-specific views directly access the
internals of views.View. However, maybe we'll simplify this further in
a later commit if we conclude that these copies of the flag are
burdensome.

The general version of this gets set directly inside the main package,
which might at some future point allow us to make the command package
itself unaware of this "running in automation" idea and thus reinforce
that it's intended as a presentation-only thing rather than as a
behavioral thing, but we'll save more invasive refactoring for another
day.

Alisdair McDiarmid

8d9a08e3a1

cli: Migrate plan to command views

Alisdair McDiarmid

68558ccd54

backend/local: Replace CLI with view instance

This commit extracts the remaining UI logic from the local backend,
and removes access to the direct CLI output. This is replaced with an
instance of a `views.Operation` interface, which codifies the current
requirements for the local backend to interact with the user.

The exception to this at present is interactivity: approving a plan
still depends on the `UIIn` field for the backend. This is out of scope
for this commit and can be revisited separately, at which time the
`UIOut` field can also be removed.

Changes in support of this:

- Some instances of direct error output have been replaced with
  diagnostics, most notably in the emergency state backup handler. This
  requires reformatting the error messages to allow the diagnostic
  renderer to line-wrap them;
- The "in-automation" logic has moved out of the backend and into the
  view implementation;
- The plan, apply, refresh, and import commands instantiate a view and
  set it on the `backend.Operation` struct, as these are the only code
  paths which call the `local.Operation()` method that requires it;
- The show command requires the plan rendering code which is now in the
  views package, so there is a stub implementation of a `views.Show`
  interface there.

Other refactoring work in support of migrating these commands to the
common views code structure will come in follow-up PRs, at which point
we will be able to remove the UI instances from the unit tests for those
commands.

3 Commits (3c8a4e6e05afefb7639bf30efa852cf59f14ade6)