[system] Change winlogbeat to Elastic agent integration in dashboard#5828
[system] Change winlogbeat to Elastic agent integration in dashboard#5828cmacknz merged 6 commits intoelastic:mainfrom nicpenning:patch-2
Conversation
The dashboards that reference this visualization comes bundled with the Windows Integrations not Winlogbeat. This will fix visualization to reference Elastic Agent integrations, not Winlogbeat
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
🤖 GitHub commentsExpand to view the GitHub comments
To re-run your PR in the CI, just comment with:
|
cmacknz
left a comment
There was a problem hiding this comment.
Thanks! Just adjusted the version and resolved the resulting conflict.
🌐 Coverage report
|
|
Package system - 1.25.4 containing this change is available at https://epr.elastic.co/search?package=system |
…lastic#5828) * Update system-bb858830-f412-11e9-8405-516218e3d268.json The dashboards that reference this visualization comes bundled with the Windows Integrations not Winlogbeat. This will fix visualization to reference Elastic Agent integrations, not Winlogbeat * Update changelog.yml * Update manifest.yml * Update version to 1.25.4 * Fix use of bug instead of bugfix. --------- Co-authored-by: Craig MacKenzie <craig.mackenzie@elastic.co>
| - description: Fix visualization to reference Elastic Agent integrations, not Winlogbeat | ||
| type: bugfix | ||
| link: https://github.com/elastic/integrations/pull/5828 | ||
| - version: "1.26.0-next" |
There was a problem hiding this comment.
Interesting. Do you have some documentation on the use case for the -next? I started seeing this so not sure on how to use it.
There was a problem hiding this comment.
The "-next"suffix means that the change is not meant to be part of a release until the the prefix. I'm not sure how we could have dealt with this here, the second step in the set of changes was delayed significantly. Probably the change here should have bumped minor rather than patch. The issue is that the kibana version changed in that PR.
There was a problem hiding this comment.
I wasn't sure how to handle this either. If we had bumped to 1.26.0 here what effect would have had on the 1.26.0-next tag? Would it have released it or just been even more confusing because we'd be at 1.26.0 with a changed still staged for 1.26.0-next?
I interpreted the -next as intended for release soon but not yet ready to release. It seemed easiest to just avoid 1.26.0 to avoid any unintended side effects, especially given that the wording change here should have just been a patch release anyway.
There was a problem hiding this comment.
Yeah, I'm not sure. I think the least worst would have been to make it a 1.26.0 release. The -next was there really to avoid excessive versions and so is essentially an optimisation.
The -next just gets ignored; the package can't know that the changes made with 1.26.0-next are only supposed to be made available when 1.26.0 becomes the current version, so it's largely just there as a placeholder for humans, but the changes associated with it end up in the new version, this was a semantic change.
The dashboards that reference this visualization comes bundled with the Windows Integrations not Winlogbeat.
This will fix visualization to reference Elastic Agent integrations, not Winlogbeat
Please label this PR with one of the following labels, depending on the scope of your change:
What does this PR do?
The dashboards that reference this visualization comes bundled with the Windows Integrations not Winlogbeat.
Checklist
changelog.ymlfile.