Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: unconnected CliIoHost logger-only implementation #32503

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

HBobertz
Copy link
Contributor

@HBobertz HBobertz commented Dec 12, 2024

Issue #32345

Closes #32345

Reason for this change

Setting the ground work for our Programmatic Toolkit

Description of changes

Created an unconnected CLIIoHost with a singular initial action available notify. In this implementation of the soon to be defined IoHost we are only writing logs to stdout and stderr.

Description of how you validated changes

Verified via unit testing as this is currently unconnected to the greater AWS CDK CLI

Checklist


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

@github-actions github-actions bot added the p2 label Dec 12, 2024
@aws-cdk-automation aws-cdk-automation requested a review from a team December 12, 2024 19:18
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Dec 12, 2024
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.

Copy link

codecov bot commented Dec 12, 2024

Codecov Report

Attention: Patch coverage is 96.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 80.59%. Comparing base (5735e9e) to head (255339e).

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #32503      +/-   ##
==========================================
+ Coverage   80.54%   80.59%   +0.05%     
==========================================
  Files         106      107       +1     
  Lines        6954     6979      +25     
  Branches     1287     1296       +9     
==========================================
+ Hits         5601     5625      +24     
  Misses       1175     1175              
- Partials      178      179       +1     
Flag Coverage Δ
suite.unit 80.59% <96.00%> (+0.05%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
packages/aws-cdk 80.59% <96.00%> (+0.05%) ⬆️

@HBobertz HBobertz marked this pull request as ready for review December 12, 2024 20:22
@HBobertz HBobertz requested a review from a team as a code owner December 12, 2024 20:22
Comment on lines 102 to 106
export const _private = {
CliIoHost,
IoMessageLevel,
IoAction,
} as const;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's so I can test it without exporting the toolkit just yet. I need to export something so I can write tests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah let's not do that. You can export things from this file. Just not from the package index.

@aws-cdk-automation
Copy link
Collaborator

➡️ PR build request submitted to test-main-pipeline ⬅️

A maintainer must now check the pipeline and add the pr-linter/cli-integ-tested label once the pipeline succeeds.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably want to call this file after its contents.

This stuff still needs to be in lib.

async notify(msg: IoMessage): Promise<void> {
const output = this.formatMessage(msg);

const stream = msg.level === 'error' ? process.stderr : process.stdout;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stream selection doesn't match what we are currently doing in this regard.

code: string;
message: string;
// Specify Chalk style for stdout/stderr, if TTY is enabled
style?: ((str: string) => string);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good thought. Is this currently used anywhere?

Beyond that, that - there's an interesting question for you: We currently use chalk inline in a number of places. How are we going to deal with that?

Might be easier to always chalk and use a global setting to deal with color vs no color.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not currently used anywhere, but I thought this would be a nice thing to add for customers when we create the IoHost interface

Copy link
Contributor Author

@HBobertz HBobertz Dec 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did some more recon on this and this is a very real problem I'm gonna need to address in a couple spots. This is enough though that I want to break that out into a separate pr, so I'll handle that in a follow up

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you explain the problem here?

Comment on lines 17 to 23
enum IoMessageLevel {
ERROR = 'error',
WARN = 'warn',
INFO = 'info',
DEBUG = 'debug',
TRACE = 'trace',
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's make this a type instead of an enum.

TRACE = 'trace',
}

enum IoAction {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's make this a type instead of an enum.

@HBobertz HBobertz changed the title chore: Unconnected IoHost logger-only implementation chore: unconnected IoHost logger-only implementation Dec 24, 2024
@aws-cdk-automation aws-cdk-automation dismissed their stale review December 24, 2024 05:12

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

@HBobertz HBobertz changed the title chore: unconnected IoHost logger-only implementation chore: unconnected CliIoHost logger-only implementation Dec 24, 2024
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: 255339e
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation aws-cdk-automation added the pr/needs-maintainer-review This PR needs a review from a Core Team Member label Dec 24, 2024
Copy link
Contributor

@kaizencc kaizencc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly nits, almost there

* Basic message structure for toolkit notifications.
* Messages are emitted by the toolkit and handled by the IoHost.
*/
interface IoMessage {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think all interface properties should be readonly. also I would expect a bit more documentation here to give me an idea of what these options do. also defaults

const stream = this.getStream(msg.level, msg.forceStdout ?? false);

return new Promise((resolve, reject) => {
stream.write(output + '\n', (err) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can the \n be part of this.formatMessage?

forceStdout: true,
});

expect(mockStdout).toHaveBeenCalledWith(chalk.white('info message') + '\n');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just curious: would this fail if you have chalk.white('info message\n')

});

describe('CI mode behavior', () => {
test('writes to stdout in CI mode regardless of level', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

based on the name of this test, I would assume that you also intend to write to stdout if the notify message is error. is that true? if so, i'd like to see a test for that case.

expect(mockStderr).not.toHaveBeenCalled();
});

test('respects forceStdout:false in CI mode', async () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm confused at this test. forceStdout: false is the default. what are you testing for here then?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, you have this in your code if (level == 'error') return process.stderr;, so regardless of ci: true an error message will be sent to stderr

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think you need a forceStdout: true test.

Comment on lines +66 to +67
if (level == 'error') return process.stderr;
return this.ci ? process.stdout : process.stderr;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you document the reasoning for why we are sending certain things to stderr and certain things to stdout?

const pad = (n: number): string => n.toString().padStart(2, '0');
return `${pad(d.getHours())}:${pad(d.getMinutes())}:${pad(d.getSeconds())}`;
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change

code: string;
message: string;
// Specify Chalk style for stdout/stderr, if TTY is enabled
style?: ((str: string) => string);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you explain the problem here?

message: string;
forceStdout?: boolean;
// Optionally specify Chalk style for stdout/stderr, if TTY is enabled
style?: ((str: string) => string);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[reviving the discussion on styling]

I thought this would be a nice thing to add for customers when we create the IoHost interface

i'm not opinionated about this either way, but isn't the point of CliIoHost to be an unopinionated 1-1 matching to what we currently have in the CDK CLI? I don't see us deciding to use custom styling beyond what our current logging styles look like.


export type IoAction = 'synth' | 'list' | 'deploy' | 'destroy';

interface CliIoHostOptions {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same comment about documentation. it's important to easily figure out what tty / ci are and why they matter when it comes to logging

@aws-cdk-automation aws-cdk-automation removed the pr/needs-maintainer-review This PR needs a review from a Core Team Member label Dec 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS. p2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IoHost logger-only implementation
4 participants