Support for having large attachments saved externally to the report

[k02pradeep]

🤔 What's the problem you're trying to solve?

Attaching images and videos in large reports is causing issue with build time and file size. Instead the images and videos can be stored in the known folder path and can be referenced by the report.

✨ What's your proposed solution?

Support for adding attachments should support passing urls for images and videos and have them referenced in the reports

⛏ Have you considered any alternatives or workarounds?

As the library does not support passing urls, other workarounds were not possible

📚 Any additional context?

---

This text was originally generated from a template, then edited by hand. You can modify the template here.

[k02pradeep]

Issue in react component

[k02pradeep]

As an alternative solution, adding mediaType text/html should be supported so that custom html content can be attached

[davidjgoss]

cc @mattwynne @mpkorstanje @brasmusson @luke-hill, this feels like a problem we should solve.

In the messages schema for an attachment, we have the url property:

This field should not be set by Cucumber...It should be set by a program that reads a message stream

This seems right to me, and I think the formatter is the program that transforms the attachment message. So something like this might work:

• The formatter has an option to externalise certain attachments by some criteria (type/size/whatever)
• The formatter is given a reference to the directory path (assuming the output stream is to a file)
• The formatter deals with creating the attachment files and transforming the messages that go to its own output stream
• Other formatters are unaffected - they still get the canonical stream of messages with attachment content inlined as base64 - and can make their own design decisions

This seems plausible in JS land, I'm not sure about the others though, what do we think?

[vitalets]

Example of such externalization that is done by cucumber-html-reporter.

[mattwynne]

Yeah that seems sensible @davidjgoss.

One of the original ideas of this message protocol was that we could use a kind of "unix pipes" approach to composing behaviour by attaching little programs to the stream in a chain. We can probably conceive of this responsibility to "unpack" the attachment message bodies as files in a directory, then forward on messages with URLs to those files, as a discrete responsibility. We could potentially build it in a separate polyglot repo if we're going to need different language implementations, with its own set of tests, then pull it into the formatters.