Commit graph

15 commits

Author SHA1 Message Date
Chris Smith 3045236dec
Record engine events concurrently (#2314)
* Record engine events concurrently

* Drop errors recording engine events
2018-12-20 15:34:30 -08:00
Pat Gavlin ded3882afd
Fix synchronization with the event renderer (#2290)
The event rendering goroutine in the remote backend was not properly
synchronizing with the goroutine that created it, and could continue
executing after its creator finished. I believe that this is the root
cause of #1850.
2018-12-13 19:58:26 -08:00
Chris Smith 84ea2f0df7
Don't emit pre-rendered update logs (#2268)
* Don't emit pre-rendered update logs

* Retry posting engine events if needed

* Update comment
2018-12-04 14:46:32 -08:00
Chris Smith 71375fe47e
Record engine events by default (#2256) 2018-12-03 08:25:58 -08:00
Pat Gavlin 9c5526e7dd
Add a --config-file option for stack ops (#2258)
This option allows the user to override the file used to fetch and store
configuration information for a stack. It is available for the config,
destroy, logs, preview, refresh, and up commands.

Note that this option is not persistent: if it is not specified, the
stack's default configuration will be used. If an alternate config file
is used exclusively for a stack, it must be specified to all commands
that interact with that stack.

This option can be used to share plaintext configuration across multiple
stacks. It cannot be used to share secret configuration, as secrets are
associated with a particular stack and cannot be decryptex by other
stacks.
2018-11-30 15:11:05 -08:00
Chris Smith ba31c6c69a
Incorporate feedback on Engine Events API (#2235)
* Add Sequence number to EngineEvents apitype

* Fix typo

* Send Timestamp with EngineEvents
2018-11-27 07:34:44 -08:00
Chris Smith 6b862e8afe Fix issue with converting keys 2018-11-09 14:01:15 -08:00
Chris Smith 8b76fd53d1
Record engine events (#2168)
* apitypes for surfacing engine events

* Add more comments to runEngineAction

* Persist engine events in the service

* Use cmdutil.IsTruthy
2018-11-09 10:01:29 -08:00
CyrusNajmabadi 8eff0e3142
Remove need to dynamically determine if we're in preview or not. (#2129) 2018-10-30 15:42:33 -07:00
Pat Gavlin b14d259365
Split large events into multiple log entries. (#2092)
Just what it says on the tin. The splitting is implemented s.t.
colorization commands are never split across multiple log entries.
2018-10-23 14:59:30 -07:00
joeduffy 3468393490 Make a smattering of CLI UX improvements
Since I was digging around over the weekend after the change to move
away from light black, and the impact it had on less important
information showing more prominently than it used to, I took a step
back and did a deeper tidying up of things. Another side goal of this
exercise was to be a little more respectful of terminal width; when
we could say things with fewer words, I did so.

* Stylize the preview/update summary differently, so that it stands
  out as a section. Also highlight the total changes with bold -- it
  turns out this has a similar effect to the bright white colorization,
  just without the negative effects on e.g. white terminals.

* Eliminate some verbosity in the phrasing of change summaries.

* Make all heading sections stylized consistently. This includes
  the color (bright magenta) and the vertical spacing (always a newline
  separating headings). We were previously inconsistent on this (e.g.,
  outputs were under "---outputs---"). Now   the headings are:
  Previewing (etc), Diagnostics, Outputs, Resources, Duration, and Permalink.

* Fix an issue where we'd parent things to "global" until the stack
  object later showed up. Now we'll simply mock up a stack resource.

* Don't show messages like "no change" or "unchanged". Prior to the
  light black removal, these faded into the background of the terminal.
  Now they just clutter up the display. Similar to the elision of "*"
  for OpSames in a prior commit, just leave these out. Now anything
  that's written is actually a meaningful status for the user to note.

* Don't show the "3 info messages," etc. summaries in the Info column
  while an update is ongoing. Instead, just show the latest line. This
  is more respectful of width -- I often find that the important
  messages scroll off the right of my screen before this change.

    For discussion:

        - I actually wonder if we should eliminate the summary
          altogether and always just show the latest line. Or even
          blank it out. The summary feels better suited for the
          Diagnostics section, and the Status concisely tells us
          how a resource's update ended up (failed, succeeded, etc).

        - Similarly, I question the idea of showing only the "worst"
          message. I'd vote for always showing the latest, and again
          leaving it to the Status column for concisely telling the
          user about the final state a resource ended up in.

* Stop prepending "info: " to every stdout/stderr message. It adds
  no value, clutters up the display, and worsens horizontal usage.

* Lessen the verbosity of update headline messages, so we now instead
  of e.g. "Previewing update of stack 'x':", we just say
  "Previewing update (x):".

* Eliminate vertical whitespace in the Diagnostics section. Every
  independent console.out previously was separated by an entire newline,
  which made the section look cluttered to my eyes. These are just
  streams of logs, there's no reason for the extra newlines.

* Colorize the resource headers in the Diagnostic section light blue.

Note that this will change various test baselines, which I will
update next. I didn't want those in the same commit.
2018-09-24 08:43:46 -07:00
joeduffy b1f7cf7050 Fix a few lint warnings 2018-09-05 08:25:23 -07:00
joeduffy 95e917441a Implement preview-then-update for local stacks
This change implements the same preview behavior we have for
cloud stacks, in pkg/backend/httpbe, for local stacks, in
pkg/backend/filebe. This mostly required just refactoring bits
and pieces so that we can share more of the code, although it
does still entail quite a bit of redundancy. In particular, the
apply functions for both backends are now so close to being
unified, but still require enough custom logic that it warrants
keeping them separate (for now...)
2018-09-05 07:33:18 -07:00
joeduffy bf51d7594a Refactor display logic out of pkg/backend/filestate
This simply refactors all the display logic out of the
pkg/backend/filestate package. This helps to gear us up to better unify
this logic between the filestate and httpstate backends.

Furthermore, this really ought to be in its own non-backend,
CLI-specific package, but I'm taking one step at a time here.
2018-09-05 07:33:18 -07:00
joeduffy feaea31f7b Rename backend packages
This renames the backend packages to more closely align with the
new direction for them. Namely, pkg/backend/cloud becomes
pkg/backend/httpstate and pkg/backend/local becomes
pkg/backend/filestate. This also helps to clarify that these are meant
to be around state management and so the upcoming refactoring required
to split out (e.g.) the display logic (amongst other things) will make
more sense, and we'll need better package names for those too.
2018-09-05 07:32:42 -07:00
Renamed from pkg/backend/cloud/state.go (Browse further)