* Reformatting and restructuring
* Update unit test
* Always send the default retention policy as first element
* Fix typo
* Update test
* Update test once more
* add NodeTypeFromDatasourceUID and DataSourceModelFromNodeType()
* deprecate expr.DataSourceModel
* replace usages of IsDataSource to NodeTypeFromDatasourceUID
* replace usages of DataSourceModel to DataSourceModelFromNodeType()
* replace condition validation with just structural validation
* validate conditions of only new and updated rules
* add integration tests for rule update\delete API
Co-authored-by: George Robinson <george.robinson@grafana.com>
Currently does not do anything as it is for use with a future enterprise PR
Eventually: "Enables writing multiple items from a single query within Recorded Queries"
* Add whatsnewchecker
* Add whatsnewchecker_test
* Small fixes
* Add step in CI
* Fix lint
* Fix starlark
* t.Cleanup instead of separate func
* Skip check for test tags
* Start local schema registry
* Try to use latest version
* Revert "Try to use latest version"
This reverts commit 682385c0e4.
* update schema registry jenny to validate new lineages
* save kind instead of lineage
* handle plugins
* get published schemas from GH + fix plugins
* handle kind not yet published
* Add script to use in workflow + handle maturity
* first pass on publish-kinds GH workflow
* fix script path
* remove unused script
* use make gen-cue instead of script
* trigger publish-kinds on every commit (for test)
* temporary update to use specific thema commit
* wrapping errors
* remove GH token & refactor for rate limit
* Update publish-kinds.yml
* Update publish-kinds.yml
* revert go.mod and go.sum updates
* use Thema specific commit
* Kind registry v2
* fix script path
* fix second script path
* update go.mod
* update schema registry source
* test checks
* add GITHUB_TOKEN
* revert test checks
* actually write next files when publishing
* Add kind set arg
* Add comments
* clean up workflows
* update Thema
* Update .betterer.results
* few fixes after lineage flattening
* Update publish-kinds-next.yml
* add codeowners for new files
* update thema
* apply review feedback
* update go version in workflows
* clean up workflows
* Add step to generate token and test
* Update publish-kinds-next.yml
* fix script
* try with the app name
* Update publish-kinds-next.yml
* clean up and update release workflow
* add comment
* publish kinds only on cue updates
* Alerting: Repurpose rule testing endpoint to return potential alerts
This feature replaces the existing no-longer in-use grafana ruler testing API endpoint /api/v1/rule/test/grafana. The new endpoint returns a list of potential alerts created by the given alert rule, including built-in + interpolated labels and annotations.
The key priority of this endpoint is that it is intended to be as true as possible to what would be generated by the ruler except that the resulting alerts are not filtered to only Resolved / Firing and ready to be sent.
This means that the endpoint will, among other things:
- Attach static annotations and labels from the rule configuration to the alert instances.
- Attach dynamic annotations from the datasource to the alert instances.
- Attach built-in labels and annotations created by the Grafana Ruler (such as alertname and grafana_folder) to the alert instances.
- Interpolate templated annotations / labels and accept allowed template functions.
* Alerting: Fix unique violation when updating rule group with title chains/cycles
The uniqueness constraint for titles within an org+folder is enforced on every update within a transaction instead of on commit (deferred constraint). This means that there could be a set of updates that will throw a unique constraint violation in an intermediate step even though the final state is valid. For example, a chain of updates RuleA -> RuleB -> RuleC could fail if not executed in the correct order, or a swap of titles RuleA <-> RuleB cannot be executed in any order without violating the constraint.
The exact solution to this is complex and requires determining directed paths and cycles in the update graph, adding in temporary updates to break cycles, and then executing the updates in reverse topological order (see first commit in PR if curious).
This is not implemented here.
Instead, we choose a simpler solution that works in all cases but might perform more updates than necessary. This simpler solution makes a determination of whether an intermediate collision could occur and if so, adds a temporary title on all updated rules to break any cycles and remove the need for specific ordering.
In addition, we make sure diffs are executed in the following order: DELETES, UPDATES, INSERTS.
* ui migration WIP
* merge
* migration tests for api
* revert chagnes to align with main
* revert chagnes to align with main
* revert chagnes to align with main
* remove unused code and comments
* revert gen files
* retry logic inplace
* fix a any
* fixed types
* migraiton results now show only result if no failures
* review comments
* wording to make it more actionable
* add migraiton summary text onyl for failed apikeys
* fixed wording and added a close button to the modal
* made the button close the modal
* moved state into component
* fix based on review, naming and removed unused code
* service account migration state optional
* making migration result undefined
* showing total and migrated numbers for a successful migration
* fix payload const to take the payload
Gábor Farkas
SatVeer Singh
ismail simsek
Nathan Marrs
Ryan McKinley
Jean-Philippe Quéméner
Yuri Tseretyan
Ivana HuckovaandMatias Chomicki
Ross
Andres Martinez Gotor
Kousik Mitra
Tania
Dimitris Sotirakis
Ezequiel Victorero
Gareth DawsonandSven Grossmann
Dan Cech
Alexander Zobnin
Jo
Kyle Brandt
Agnès Toulet
Matthew Jacobson
Isabella Siu
Andrew Hackmann
Santiago
Will Browne
Kevin Yu
Andreas Christou
Eric Leijonmarck
Ludovic Viaud