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

feat: implement status report #224

Merged
merged 4 commits into from
Jul 28, 2022
Merged

Conversation

puskuruk
Copy link
Contributor

@puskuruk puskuruk commented Jul 13, 2022

Implements #133

  • Tests pass
  • Appropriate changes to README are included in PR

@puskuruk puskuruk changed the title [WIP] feat: implement status report feat: implement status report Jul 13, 2022
Copy link
Collaborator

@ergunsh ergunsh left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution! This is exactly how I imagined the status report would work :)

I've added a few comments and nits. Though, in overall, I'd like @OrKoN to review this CL as well especially for the usage of 3rd party libraries.

In addition to that, I have a few more suggestions somewhat related to this feature but not in the scope of this PR:

  • Maybe we can combine the status report with "run" status. For example, when the user has run the CLI for some recordings, instead of logging "Running the recording X" and "Finished run X" we can directly present the table like
Recording Title Status Path etc
My Recording Running ...
2nd recording Pending ...
  • At the end of the run, until the control returned back to the user (while the browser is being closed) there is a time. It feels like the run has stuck at that moment, maybe we can provide some output for saying something like "Cleaning up the run..."

src/CLIUtils.ts Outdated Show resolved Hide resolved
src/CLIUtils.ts Outdated Show resolved Hide resolved
@@ -112,9 +180,19 @@ export async function runFiles(
opts.log && console.log(`Finished running ${file}`);
} catch (err) {
opts.log && console.error(`Error running ${file}`, err);
throw err;
Copy link
Collaborator

Choose a reason for hiding this comment

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

This change changes the behavior of the CLI:

  • Before: when a replay is failed, we were throwing error from here so that the yargs library was returning the status code 1 to the bash
  • With this change: even though a replay is failed, we now return control to the user with status code 0.

We want to return status code 1 when a replay is failed since this makes the library more useful especially in CI workflows (i.e. if a replay is failed, CI will report the task to be failed as well)

So, can you restore the old behavior of throwing an error? (It's fine running all the results, I guess at the end of all runs, we can check whether there is a replay result with failure and if so throw an error -- though up to you 😂)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for your feedback @ergunsh . I've restored old behavior with throwing an error but we continue to run all the recordings 🙏 What do you think about running all the recordings even though a replay has failed? @OrKoN

test/cli.test.ts Outdated Show resolved Hide resolved
package.json Show resolved Hide resolved
@ergunsh ergunsh requested a review from OrKoN July 15, 2022 08:27
@puskuruk
Copy link
Contributor Author

puskuruk commented Jul 18, 2022

Thank you for your review @ergunsh 🙏

I liked your suggestion of showing the current status of each recording dynamically. I didn't implement it before but I've started to look at what are the approaches for implementing dynamic logs.

@OrKoN
Copy link
Collaborator

OrKoN commented Jul 28, 2022

Thanks for working on this!

@puskuruk
Copy link
Contributor Author

The branch was behind the main branch, so I rebased it with main again. 🙏

@OrKoN OrKoN merged commit d9c368f into puppeteer:main Jul 28, 2022
@OrKoN
Copy link
Collaborator

OrKoN commented Jul 28, 2022

@puskuruk it looks like the color.js is not the best module from a security perspective https://security.snyk.io/vuln/SNYK-JS-COLORS-2331906 Could we replace it with https://github.com/jorgebucaran/colorette or another alternative?

@puskuruk
Copy link
Contributor Author

Nice catch @OrKoN! I'll update it ASAP 🙏

@Chrfrs

This comment was marked as spam.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants