Now allows for specifying a `group` value for each section which will
cross product the sections within that group with the sections in each
other group. Additionally classifiers will automatically be added to
each job spec with the relevant group information.
Ensure that a plug-ins config entry is converted to an identifier before being
stored in the PluginCache so that the relevant configuration can be
retrieved appropriately. For example this allows for both 'trace-cmd' and
'trace_cmd' to be used as config entries to provide configuration for the
'trace-cmd' plugin.
- Add copyright headers to files that did not already have them
- Update the year to the last year the file was modified in files with
existing headers.
If more then one of augmentation entries ("augmentations",
"instrumenatation", "output_processors") is specified in the same
config they were being merged into a single entry.
This can cause issues with '~~' (drop everything glyph) being "resolved"
during this merge and therefore not actually used to drop all previous
augmentations.
Union'ing, instead of merging, configs at the same level avoids that.
Note that this is semantically correct, as we're not enforcing
precedence at the same level of config, so merge semantics do not apply.
Add support for "~~" special value that indicates that, when merging
into another set, all values from that set should in fact be dropped.
Apart from the unique merge semantics, "~~" just like any other "~"
value.
If WA is ran without any workloads being specified, previously an index
error was thrown, now check that at least one global workload has been
specified and if not, provide a more helpful error message.
Remllace merge_instruments_result_processors with merge_agumentations
which is updated to properly merge the new unified "augmentations"
configurations.
Rename ConfigurationPoint "instrumenation" to "augmentations". Unlike
WA2, in W3, instruments and result_porcessors are handled identically in
configuration (though there're still distinct pulgin types).
"instrumentation" and "result_porcessors" entries in configuration are
now aliases for the same configuration point, which is renamed to
"augmentations" to reflect the fact that it contains both types of
plugins.
When both global and config sections are present in an agenda, they both
will be processed by the ConfigManager. In each case, the path to the
agenda file was specified as the source, which resulted ConfigManager
complaining that the same source is being added twice. To avoid that,
the source is now suffixed with the section name.
"params" is interpreted differently in section vs workload entires in
the agenda; previously, this was handled in the generic entry
construciton function by examining the ID prefix of the entry to
distinguish between the two.
This is unreliable as the user may specify their own IDs that won't have
the expected prefixes. To handle this, the "params" alias resolution for
sections is now handled in section specific part of entry processing
(workloads are handled autmatically because that is the default for
the corresponding JobConfig config point).
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
Changing the way target descriptions work from a static mapping to
something that is dynamically generated and is extensible via plugins.
Also moving core target implementation stuff under "framework".
