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

- Adding possibility of setting env, configDir and disable html repor… #1429

Merged

Conversation

joelpramos
Copy link
Contributor

@joelpramos joelpramos commented Jan 10, 2021

Description

Thanks for contributing this Pull Request. Make sure that you submit this Pull Request against the develop branch of this repository, add a brief description, and tag the relevant issue(s) and PR(s) below.

Adding parameter that allows debug server to be reused - when debug session terminates VS Code disconnects but debug server continues to run

As I run my own framework on top of Karate one of the things that I always wanted to avoid was the System.exit() that happens after the debug session. I used to have some weird workarounds with the Java Security Manager but introduced a variable (exitAfterDisconnect) which allows that behavior to be controlled. With it you can create a debug that doesn't terminate the JVM (just disconnects the session) server by extending DapServer class and setting that parameter as false.

The behavior from VS Studio Code is just that the debug session will terminate so it's seamless to the user.

Adding possibility of setting env, configDir and disable html report via debugger in VS Code

With Karate v1.0.0 allowing env to be passed in the runner and a configDir I externalized all configurations and use variables in all test cases but the debugger needs to run against a certain environment. This allows the parameters to be passed in the karateOptions of the Karate Runner in VS Code. Here's an example of the field in the Runner:

"karateOptions": "\"${command:karateRunner.getDebugFile}\" \"--configdir=C:\\test_cases\\config\" \"--env=dev01\"",

@ptrthomas let me know your thoughts. Might be good to tag the maintainer of the Karate Runner to check it out.

  • Relevant Issues : (compulsory)
  • Relevant PRs : (optional)
  • Type of change :
    • New feature
    • Bug fix for existing feature
    • Code quality improvement
    • Addition or Improvement of tests
    • Addition or Improvement of documentation

…t via debugger in VS Code

- Adding parameter that allows debug server to be reused - when debug session terminates VS Code disconnects but debug server continues to run
@joelpramos
Copy link
Contributor Author

btw having to wrap each parameter with quotes seems kind of weird... but that's the behavior supported by the function in Karate that parses CLI arguments. was it intended?

@ptrthomas
Copy link
Member

cc @kirksl and @ivangsa I think you have some good idea about the double-quotes issue. it may take me a couple of days to get to this, any inputs welcome in the meantime

@@ -94,6 +94,9 @@
@Option(names = {"-o", "--output"}, description = "directory where logs and reports are output (default 'target')")
String output = FileUtils.getBuildDir();

@Option(names = {"-r", "--htmlreport"}, description = "output html report enabled (default 'true')")
Copy link
Member

Choose a reason for hiding this comment

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

prefer --report if that sounds okay. here is where potentially can add more flags in future similar to --format

I was wondering if a system to prefix ~ to disable works, e.g. (not needed now, just seeing if makes sense to you)

-r ~html,~json - which means don't emit html and JSON reports which are both by default

Copy link
Contributor

Choose a reason for hiding this comment

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

btw having to wrap each parameter with quotes seems kind of weird... but that's the behavior supported by the function in Karate that parses CLI arguments. was it intended?

Hi @joelpramos it's weird but parsing options works well with short options (i.e: -e) but long options (--env) needs quoting, this must be something related to picocli

This works fine, but if using long options version it fails

    @Test
    void testParsingCommandLine7() {
        Main options = IdeMain.parseIdeCommandLine("-H com.intuit.karate.cli.VSCodeHook -t ~@ignore -e local -g W:\\dev\\sandbox\\karate-1.0.0-tests\\src\\test\\resources w:\\dev\\sandbox\\karate-1.0.0-tests\\src\\test\\resources\\todos.feature:27");
        assertEquals(1, options.paths.size());
        assertEquals(1, options.tags.size());
        assertEquals(1, options.hookFactoryClassNames.size());
        assertEquals("local", options.env);
        assertEquals("W:\\dev\\sandbox\\karate-1.0.0-tests\\src\\test\\resources", options.configDir);
    }

Copy link
Contributor

Choose a reason for hiding this comment

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

also this looks very elegant: -r ~html,~json

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah I like that much more elegant

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ptrthomas what if I change to the --format instead and remove the new property I added but make sure that html is enabled by default unless explicitly negated (~html)?

Copy link
Member

Choose a reason for hiding this comment

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

@joelpramos agreed. I'd try to fit a colon maybe e.g. cucumber:json but fine otherwise also

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense. I was reviewing the usage of the Karate JSON report and I'm not certain whether it can be disabled - the Results object is always instantiated out of the File object where that JSON is stored. I assume it's related with the distributed testing.

We could try to refactor to allow it to be disabled but produce an error if you try using through JobManager with it disabled but I don't really have that set up yet.

It doesn't truly impact my use case as I was just trying not to store anything during a debug session but it's not breaking anything. Maybe I can add a Hook that is executed after the Suite in a debug session to clear any files that are produced?

Copy link
Member

Choose a reason for hiding this comment

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

@joelpramos great point thanks. I propose that if the user disables the karate json it will disable the karate html also or at least the summary HTML and printing the final results tally to the sys.out

I was contemplating an option where the JSON would be kept in memory until the end of the test, but not worth it maybe

Copy link
Member

Choose a reason for hiding this comment

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

just to clarify - the reason to persist the JSON is not just for distributed testing, but to save memory for a large suite. otherwise we would be accumulating lots of objects just for the sake of the summary report. come to think of it there is a feature-summary json you can see used in the Results class. maybe that could suffice. agh so many decisions >_<

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll leave it for now and maybe try to create a Hook for the debugger later to clear the created files after the tests are done. Can probably be enabled by default to the debugger but might even be useful for CI/CD pipelines if we only care about the logs of the execution or if you integrate with an external system (I use report portal and I also zip the HTML report and ship it there).

@joelpramos
Copy link
Contributor Author

joelpramos commented Jan 11, 2021

Update completed and made the default output dir of the debugger end with a timestamp so multiple executions don't override the previous reports.

Copy link
Contributor Author

@joelpramos joelpramos left a comment

Choose a reason for hiding this comment

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

ready to review again

// create a subfolder so multiple executions don't override the previous reports
String outputDir = options.getOutput();
if(outputDir.contentEquals(FileUtils.getBuildDir())) {
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyyMMdd_HHmmss");
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yup all good - I searched by date formatter usages and couldn't spot any which is why added it. I think the important part here is being a unique folder for local debugging - different use case than a CI/CD for example where you always want in the same folder for your Jenkins/etc to pick it up from there.

@ptrthomas ptrthomas merged commit 47638e0 into karatelabs:develop Jan 13, 2021
ptrthomas added a commit that referenced this pull request Jan 13, 2021
decided to default the behavior of backing up reports folder to true and added runner builder flag
some code re-use for parsing cli options
@ptrthomas
Copy link
Member

@joelpramos can you review this update over your changes: 6436b2c

@joelpramos
Copy link
Contributor Author

@joelpramos can you review this update over your changes: 6436b2c

is the backup dir printed somewhere? wondering whether we can also add it in that System.out.print() report that shows up after Suite is complete where we see the other link.

@ptrthomas
Copy link
Member

@joelpramos good idea, one extra log statement maybe - go ahead and suggest / PR

ptrthomas added a commit that referenced this pull request Jan 13, 2021
@ptrthomas
Copy link
Member

@joelpramos actually the summary report always has the link to HTML file (full path) may be enough

I just added a log statement, hope that suffices

@joelpramos
Copy link
Contributor Author

@joelpramos actually the summary report always has the link to HTML file (full path) may be enough

I just added a log statement, hope that suffices

great by me, thanks

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.

3 participants