Resolve "Group Level API support for Deployment Frequency" [RUN ALL RSPEC] [RUN AS-IF-FOSS]
What does this MR do?
- Related to #291747 (closed)
- Follows from: #291747 (closed)
- Built upon: !48265 (merged)
- Blocked by: !52919 (merged)
Adds Group level Deployment Frequency API similar to the existing one for Projects.
- I changed all instances of
project_activity_analytics
todora4_analytics
. The new Group level deployment frequency is gated by this policy. So is the existing Project level deployment frequency. The policy was also used a couple other places. CC @nfriend - The Group level API works exactly the same as the Project level API except that it's across all Projects within the given Group. I implemented this in the Finder class.
- I updated the documentation and added new documentation for the Group level API.
- All other changes are just boilerplate.
TODO
-
As per this comment !51938 (comment 491179854) -- introduce a development feature flag to guard potentially slow query. -
Get @ogolowinski thoughts on !51938 (comment 494453928) and potentially filter out deleted/archived projects if we want to do that. -
Figure out how best to factor the very non-DRY code in the RESTful API class. See !51938 (comment 494457820) for more information. -
Update the spec tests as per !51938 (comment 493389209) and !51938 (comment 493389227) to include some projects with successful deployments that are not part of the group we're testing so that we can see those deployments are correctly filtered out of our result sets. -
Rename some variables in spec tests as per ee/spec/finders/analytics/deployments_finder_spec.rb
for clarity. -
Figure out how to format datetimes consistently as per !51938 (comment 494471346) -
Rebase on this MR once it's merged: !52288 (closed) -- This will require significant non-trival re-working of this code.Don't wait to rebase. -
Implement filter by visibility on the Finder if it's possible for a user to have reporter for a group by not have any access or not have reporter access to a project within that group. See !51938 (comment 495518754) for more details. -
Update implementation and spec tests to account for subgroups.
Database
See analysis here !51938 (comment 501971108)
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - [-] Tested in all supported browsers
- [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
- [-] Label as security and @ mention
@gitlab-com/gl-security/appsec
- [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
- [-] Security reports checked/validated by a reviewer from the AppSec team
Edited by Mayra Cabrera