Add Metrics Dashboard embed pipeline to FF
What does this MR do and why?
This MR gates the metrics dashboard embeds pipeline functionality behind the remove_monitor_metrics
feature flag. Frontend is done, but we also want to deprecate/remove any API-only access.
Related issue: Metrics: Delete GFM pipeline logic for embeds (#397137 - closed), (one of many MRs)
Context for removal:
- The Metrics Dashboard feature is being removed in %16.0.
- Most of the metrics dashboard frontend is currently behind the
remove_monitor_metrics
flag, but the flag has not yet been enabled. It needs to be enabled by default in time for %16.0.- The entire frontend should be behind the flag in order to enable it by default, but the API can merge after - as long as we make all breaking changes within %16.0.
- Rollout issue: [Feature flag] Rollout of `remove_monitor_metrics` (#399248)
- Tracking issue: Metrics: hide deprecated modules behind a featu... (#399231 - closed)
- Enable-by-default MR: Set remove_monitor_metrics flag to true (!119989 - merged)
backend MRs to flag all metrics dashboard endpoints
All related- Add Metrics Dashboard annnotations API to FF (!120286 - merged)
- Add Metrics Dashboard starred dashboard API to FF (!120288 - merged)
- Add Metrics Dashboard templates viewer to FF (!120289 - merged)
- Add Metrics Dashboard environments API to FF (!120299 - merged)
- Add Metrics Dashboard settings API to FF (!120305 - merged)
- Add Metrics Dashboard GraphQL alert queries to FF (!120307 - merged)
- Add Metrics Dashboard embed pipeline to FF (!120310 - merged)
- Add Metrics Dashboard for internal dashboard en... (!120313 - merged)
- Add Metrics Dashboard base API to FF (!120316 - merged)
How to set up and validate locally
** pre-req: project with an environment
operation | how to test | before | after |
---|---|---|---|
Environment metrics embed |
Pre-req: project with an environment
Note: edit the markdown after swapping the flag to reset the cached version |
The metrics-related error is because of the frontend finding the dashboard & attempting to retrieve data. But my local env doesn't actually have a prometheus server returning data, so we just get an error |
There's no error because we're not including a placeholder embed for the frontend to latch onto |
Cluster metrics embed |
Pre-req: project with a cluster ```ruby FactoryBot.create(:cluster, projects: [Environment.last.project], user: User.last) ```\ 1. Same as the previous one!
|
||
Alert metrics embed |
Pre-req: alert --> See !120307 (merged) for setup instructions
|
||
Grafana metrics embed |
Pre-req: grafana integration
|
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Merge request reports
Activity
changed milestone to %16.0
assigned to @syasonik
1 Warning e34b637e: Commits that change 30 or more lines across at least 3 files should describe these changes in the commit body. For more information, take a look at our Commit message guidelines. 1 Message CHANGELOG missing: If you want to create a changelog entry for GitLab FOSS, add the
Changelog
trailer to the commit message you want to add to the changelog.If you want to create a changelog entry for GitLab EE, also add the
EE: true
trailer to your commit message.If this merge request doesn't need a CHANGELOG entry, feel free to ignore this message.
Reviewer roulette
Changes that require review have been detected!
Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:
Category Reviewer Maintainer backend Joseph Joshua (
@joseph
) (UTC+0, 4 hours ahead of@syasonik
)Kerri Miller (
@kerrizor
) (UTC-7, 3 hours behind@syasonik
)test for spec/features/*
Joseph Joshua (
@joseph
) (UTC+0, 4 hours ahead of@syasonik
)Maintainer review is optional for test for spec/features/*
To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
DangerEdited by Ghost Usermentioned in merge request !120286 (merged)
mentioned in merge request !120288 (merged)
mentioned in merge request !120289 (merged)
mentioned in merge request !120299 (merged)
mentioned in merge request !120305 (merged)
mentioned in merge request !120307 (merged)
mentioned in merge request !120309 (closed)
mentioned in merge request !120313 (merged)
mentioned in merge request !120316 (merged)
- Resolved by Vitali Tatarintev
@hmehra Could you do backend review for this MR?
There are a bunch of related MRs, so I'm going to assign some of the others to you as well. If you don't have the capacity, that's totally fine. If you could just reassign to another backend reviewer, that'd be great!
When this MR is ready, let's pick any of [
@ck3g
(Germany) /@splattael
(Germany) /@rkadam3
(India) ] for backend maintainer review to get grouprespond domain expertise as well. Whoever seems to have capacity or is in the "upcoming" timezone is perfect.
requested review from @hmehra