I want to change the log display style when I run sam deploy

[madakaheri]

Describe your idea/feature/enhancement

When running sam deploy, stack events and error messages are always printed in a fixed columnar table format.
This format is sometimes hard to work with, especially when logs are consumed in CI/CD or redirected to files.
Unlike the AWS CLI --output option (which controls API response formatting), this request is specifically about the log display style of deployment progress.

Proposal

Add a dedicated option (for example, --log-format) to control how deployment logs are displayed.

• Default remains the current table format.
• Possible alternatives: raw, compact, or structured formats such as JSON/YAML.
• This would not affect the final SAM outputs, only how logs are streamed to the user.

Things to consider

1. No change to the SAM Spec is required.
   This is purely a CLI usability improvement.

Additional Details

Example:

sam deploy --log-format text

[dcabib]

I'm a bit skeptical about adding another formatting option here. The table format exists specifically because CloudFormation stack events are inherently structured data with multiple columns (timestamp, resource type, status, reason, etc.), and a table is the most readable way to present that during an active deployment. If you're piping to a file or consuming in CI/CD, can't you just parse the existing output? Most CI/CD systems handle multi-line output just fine, and if you need machine-readable data, you could always query the CloudFormation API directly after deployment completes.

I'm also wondering what your actual pain point is here. Are the columns wrapping badly in your terminal? Is it about filtering specific events? Because if it's about getting structured data for post-processing, the CloudFormation describe-stack-events API already returns JSON that you can query however you want. Adding --log-format json to stream events during deployment feels like it would just dump a bunch of JSON objects to stdout in real-time, which seems harder to follow than the current table, not easier. What specific workflow are you trying to enable that doesn't work with the current format or with querying the API afterward?