Add ability to mock out process.stdout calls about toolkit

[jeffrafter]

It is also possible to mock this globally in the jest.config.js:

const processStdoutWrite = process.stdout.write.bind(process.stdout)
process.stdout.write = (str, encoding, cb) => {
  // Note: this will soon change to ::
  if (!str.match(/^\#\#/)) {
    return processStdoutWrite(str, encoding, cb)
  }
}

[jasonkarns]

@ericsciple I don't think it's just as simple as mocking core. I'm using the tool-cache module and getting all the debug messages triggered by tool-cache. I can't mock @actions/core because tool-cache has its own copy of the module. (@actions/core isn't de-duped in my node_modules tree; but even if it were, that would be a pretty fragile mock to assume they would always de-dupe)

[bryanmacfarlane]

Thanks for logging this issue! We will implement this (we also take PRs ;) )

[xt0rted]

These log messages from tests are now causing annotations to be created when they shouldn't be. You can see an example of this in my most recent action run here https://github.com/xt0rted/slash-command-action/pull/34/checks?check_run_id=259915650#step:8:9 and here https://github.com/xt0rted/slash-command-action/pull/34/checks?check_run_id=259915650#step:8:63.

[bryanmacfarlane]

@xt0rted - not related to mocking but I think proper annotations support will fix your issue. I can prioritize the first half of that work (ensuring logging warning / error output doesn't create an annotation). That's a bug and I can fix. Sound ok? #186

[xt0rted]

@bryanmacfarlane I meant to post that on #163, both issues a pretty similar in their end goal.

[ericsciple]

would mocking the command module make more sense?

[ericsciple]

Example here where core is mocked out specifically to capture info.

Example here where core is mocked out to control the function results.

Users can leverage mocking tools to fit their specific needs.

[ericsciple]

@jasonkarns good point regarding dedupe

[bryanmacfarlane]

This is what we do in setup-go tests to mock it.

https://github.com/actions/setup-go/blob/master/__tests__/setup-go.test.ts#L49

So, you're not mocking core wit a need for understanding internal. You're getting console writes so mock that.

It's not the toolkit's role to add mocking for stdout. There's plenty of mocking frameworks that are capable of mocking stdout (as per above). Action authors should use the testing and mocking framework that suits them.

[thboop]

Closing this as workarounds are identified and we are unlikely to add it to the toolkit in the near future.