messages: extend javascript message type with workerId

[epszaw]

Summary

Provide optional workerId property to Message type

Details

workerId property, which can be useful for some cases, when you need to capture additional testing details. The changes required only for javascript message type because most of another platforms don't have problem with thread ID identifying.

Then I want to provide additional PR for cucumber-js where I plan to use the property.

Motivation and Context

allure-cucumberjs needs to have access to thread or worker id for better reports.

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).

Checklist:

• The change has been ported to Java.
• The change has been ported to Ruby.
• The change has been ported to JavaScript.
• The change has been ported to Go.
• The change has been ported to .NET.
• I've added tests for my code.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have updated the CHANGELOG accordingly.

[aurelien-reeves]

The file you have updated is an automatically generated file. Your changes won't be kept. In order to make changes to the messages protocol you need to update the json schemas, then regenerate the code

Also, the messages protocol is implementation agnostic. Generic. We cannot and do not want to add a property into a single language.

Thus, your workerId attribute is too specific to cucumber-js. I am not sur such change would be accepted.

What is your exact need related to cucumber-js? We can certainly find other ways to help!

[baev]

In Allure we have a Timeline graph that visualises how tests were executed across hosts and threads:

So we are looking for ways to implement it for cucumber-js since it now has parallel mode.

[epszaw]

I think, we can extend the type right in the cucumber-js repo. It that way, we'll keep original interface and provide what we need in the library

[epszaw]

Like this:

Message & { workerId?: string }

[aurelien-reeves]

I think, we can extend the type right in the cucumber-js repo. It that way, we'll keep original interface and provide what we need in the library

I think so, yes 👌

Thanks for your understanding 🙂

How do you integrate cucumber-js with allure? Do you use a custom formatter?

[epszaw]

How do you integrate cucumber-js with allure? Do you use a custom formatter?

Yes, we do. You can check it here

[aurelien-reeves]

Ok, thanks

Adding the workerId as part of the formatter is not possible? (this is a legit question!)

[epszaw]

Ok, thanks

Adding the workerId as part of the formatter is not possible? (this is a legit question!)

It would be possible only if the messages contain workerId. At this moment we don't have access to any worker env-variables then, we can't know which worker it was.

I opened a PR to cucumber-js and it adds the logic with batch of documentation:

const { Formatter } = require('@cucumber/cucumber')
class ExampleFormatter extends Formatter {
  constructor(options) {
    options.eventBroadcaster.on('envelope', (envelope) => {
       if (envelope.workerId) {
         console.log(`the envelope was sent from a worker with id ${envelope.workerId}`)
       } else {
         console.log('the envelope was sent outside of any worker')
       }
    })
    super(options)
  }
}
module.exports = ExampleFormatter

[aurelien-reeves]

Thanks 👍

Refs. cucumber/cucumber-js#2085