Closed flash1293 closed 2 days ago
Thanks @simianhacker - added that:
I also extended the logic a bit to clean up the processor in the user-managed pipeline if the stream gets deleted so the user has a safe way to get rid of it.
Should be good for another look.
I will add some integration tests for this on a follow-up PR.
Fewer modules leads to a faster build time
id | before | after | diff |
---|---|---|---|
streamsApp |
149 | 152 | +3 |
Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app
id | before | after | diff |
---|---|---|---|
streamsApp |
95.5KB | 96.1KB | +587.0B |
Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0.
Run node scripts/build_api_docs --plugin [yourplugin] --stats exports
for more detailed information.
id | before | after | diff |
---|---|---|---|
streams |
4 | 3 | -1 |
Starting backport for target branches: 8.x
Status | Branch | Result |
---|---|---|
✅ | 8.x |
Note: Successful backport PRs will be merged automatically after passing CI.
Please refer to the Backport tool documentation
This PR allows to add processing to classic streams.
When defining processing for a classic stream, it will add a reference to the
<stream name>@stream.processing
pipeline to the default pipeline of the stream (or a@custom
sub pipeline if it exists). Then, it will write processing rules like for wired streams.On the UI, the processing tab is not implemented yet, but this PR also prepares that there are two tabs (overview and enrich) shown for classic streams, not just an overview page.