-
Notifications
You must be signed in to change notification settings - Fork 218
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
Add grafana_folders
data source for fetching all folders
#583
Conversation
Signed-off-by: Mike Ball <mikedball@gmail.com>
Signed-off-by: Mike Ball <mikedball@gmail.com>
Signed-off-by: Mike Ball <mikedball@gmail.com>
This seeks to address: ``` grafana/data_source_folders.go:5:2: G501: Blocklisted import crypto/md5: weak cryptographic primitive (gosec) "crypto/md5" ^ grafana/data_source_folders.go:71:9: G401: Use of weak cryptographic primitive (gosec) md5 := md5.Sum([]byte(strings.Join(uids, "-"))) ^ ``` Signed-off-by: Mike Ball <mikedball@gmail.com>
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.
Nice one. Just a small comment about the ID
Per @julienduchesne (https://github.com/grafana/terraform-provider-grafana/pull/583/files#r944357467): > The ID should be declarative because it needs to be unique. For a datasource like this, it's usually the combination of all entry parameters because you will typically not have the same datasource twice with the same parameters, it's useless > With no parameters, you can just set the ID as grafana_folders. No need to calculate a SHA Signed-off-by: Mike Ball <mikedball@gmail.com>
Thanks @julienduchesne - I've implemented your suggestion, assuming I interpreted correctly :) |
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! Thanks!
This seeks to address issue #377 by adding a
grafana_folders
data source, which can be used to fetch all Grafana folders.Note that this is an alternative implementation to that contained in PR #389, which I admittedly only noticed just now (I apologize) and which appears to have gone stale with git conflicts and an unsigned CLA. Would maintainers prefer I close this PR in favor of the PR #389 implementation?