-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validate that dashboard IDs start with package names #66
Conversation
versions/1/kibana/spec.yml
Outdated
@@ -9,7 +9,7 @@ | |||
- description: A dashboard asset file | |||
type: file | |||
contentMediaType: "application/json" | |||
pattern: '.+\.json' | |||
pattern: '{PACKAGE_NAME}+-.+\.json' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting idea - to allow certain keywords in the spec that can act as variables/placeholders whose value depends on the context. TBH, this is not how I had imagined implementing semantic validations but I like it - its simple! Let's go with this idea and see how far we can take it.
We should probably document these keywords somewhere (outside the spec, of course) for spec developers so they know which keywords are available to them and what they mean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think about README or CONTRIBUTING file in package-spec or somewhere else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think CONTRIBUTING is the right place for this sort of thing. Let's try to keep the README more for spec consumers and CONTRIBUTING for spec contributors, although there might be some overlap/fuzziness, which is okay IMHO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a short one.
for _, itemSpec := range s.Contents { | ||
if itemSpec.Name != "" && itemSpec.Name == folderItemName { | ||
return &itemSpec, nil | ||
} | ||
if itemSpec.Pattern != "" { | ||
isMatch, err := regexp.MatchString(itemSpec.Pattern, folderItemName) | ||
isMatch, err := regexp.MatchString(strings.ReplaceAll(itemSpec.Pattern, "{PACKAGE_NAME}", packageName), folderItemName) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Validating that the dashboard file name starts with the package is a good start. But we also need to implement two more related validations:
- validating that the ID of the dashboard, as defined in the dashboard asset JSON file, starts with the package name or, better yet, matches the file name (sans extension) of the dashboard asset JSON file, and
- validating that there aren't any references to the dashboard ID with the package name prefix removed.
For both these additional validations, I think you'll need to define the spec files for Kibana assets. I was hoping to avoid this but I think we have to bite that bullet now. Perhaps we could define them with only the fields we need and leave the rest open-ended (that is, allow additional fields in the asset file that are not explicitly defined in the spec)?
If you want to tackle these additional validations in a separate PR that's fine by me. In that case, just update the issue corresponding to this PR with a checklist of the 3 total validations so we can keep track of the work done vs. remaining.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the first point (validating the ID of the dashboard inside the file). I can introduce the schema for dashboard file. We might need to introduce the binding between ID and packageName also there.
Regarding the second point, it's hard to implement it as it's mainly "search and replace" operation and we may fail the validation if there are references between dashboards in different packages (e.g. jump to the system dashboard).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's break these out into follow up PRs. Implementing the first point will introduce more files so let's not bloat this PR with those. Implementing the second point might be tricky as you pointed out so let's keep that out of scope for this PR. What you have in this PR here is already useful so let's move that forward first.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the second point, it's hard to implement it as it's mainly "search and replace" operation and we may fail the validation if there are references between dashboards in different packages (e.g. jump to the system dashboard).
Visualization used by the dashboard should all be contained within the same integration (we cannot include a visualization from a different integration, as it may not be installed). Are you thinking about links here? Most of what we have is just visualizations, and their IDs should match this pattern.
++ on following up with these cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps let's not close #65 until the other PRs get in?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, Carlos. I updated the description.
I'll merge this PR as it's already an improvement. We can work on follow up PRs then. EDIT: Unfortunately I don't have permissions to overwrite required approvals in this repository. |
Is this only about dashboards or also visualizations, searchs etc? |
It's only for dashboards (according to the email thread). |
I would assume we also have conflicts on visualizations, search etc? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for jumping into this so quick!
I tried to reproduce it and we might need to update ID references one more time, @ycombinator . How to reproduce it:
Then navigate to the system dashboard which may be scrambled. I'm not quite sure about the previous fix elastic/integrations#171 , which only covered dashboards. In the worst case we need to wrap up a similar fix to elastic/integrations#319 for visualization and searches, and the same way iterate on other PRs related to it. |
Yes, I will work on a PR today to the @elastic/integrations repo for fixing any visualization and saved search IDs. [EDIT] @mtojek can you work on any corresponding changes to the migration script? |
|
||
Currently, the following placeholders are available: | ||
|
||
* `{PACKAGE_NAME}` - name of the package |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
I started to create this PR but ran into an issue that needs some discussion. Please take a look: elastic/integrations#334 (comment) and continue the discussion on that issue (not here). Thanks! |
Thank you for adjusting the issue. I wonder if we shouldn't include all these changes in a single PR. Otherwise we'll end up in few iterations on adjusting integrations and spec. Or I will wait with merging this one, until all packages are in a good shape in terms of dashboard names (to merge elastic-package dependency update). EDIT: I will try now, I suppose they should be correct now.
Yes, that's on my TODO list. |
Issue: #65