Multi-line strings in meta, parameter_meta
See original GitHub issueIf we want to put rich information in there, we should allow >1 line of text. We could maybe re-use the triple-angle brackets style, eg:
workflow foo {
meta {
description: <<<
# Foo.wdl
---
This could be a looo...
...
...
...oong Markdown description of the workflow, for example
>>>
}
}
Issue Analytics
- State:
- Created 5 years ago
- Reactions:2
- Comments:5 (3 by maintainers)
Top Results From Across the Web
Using a Jenkins pipeline multiline /multi-line string parameter
I discovered the solution by looking at the Jenkins source code: parameters{ text(name: 'mytextparam', defaultValue: 'Default lines for the ...
Read more >Template literals (Template strings) - JavaScript | MDN
Template literals are literals delimited with backtick (`) characters, allowing for multi-line strings, string interpolation with embedded ...
Read more >Metadata format: metadata is not a plain mapping of strings
Almost all build backends assume metadata to be a plain mapping of strings (distutils, setuptools, flit, poetry, etc.)
Read more >LLVM Language Reference Manual
Metadata nodes (but not metadata strings) are the only valid operands for a named metadata. Named metadata are represented as a string of...
Read more >Writing YARA rules — yara 4.2.0 documentation
This is a multi-line comment . ... This limitation does not apply to strings in the metadata section or comments. ... The alphabet...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
👍 to the idea of adding the multi-line string literal and thereby gaining the ability to use it in meta
Longer term, it seems like we could go in a Javadoc-like direction where documentation is in comments adjacent to the thing it describes.
This would let us generate documentation from the workflow with a documenting tool, but would exclude the documentation strings from appearing anywhere at runtime. (Engine-specific hints would still live in
*meta
.)We in Mint need some kind of abstraction that allows us to add documentation to WDL files. We’re currently using
meta
andparameter_meta
to do this, as there doesn’t appear to be a better alternative.Without multi-line strings, they make our files pretty hideous, so big 👍 on this issue.