[SERVER-70052] Investigate static analysis mechanism for enforcing architectural rules Created: 28/Sep/22  Updated: 27/Oct/23  Resolved: 27/Oct/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Jordi Serra Torrens Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-70047 Add linter rule that checks Collectio... Closed
is related to SERVER-68247 Support mongo-authored clang-tidy plu... Closed
is related to SERVER-71770 Move CollectionShardingRuntime into c... Closed
Assigned Teams:
Server Development Platform
Participants:

 Description   

SERVER-70047 adds a new linter rule meant to enforce an architectural rule. This ticket is to investigate a better suited place where the source of truth for architectural decisions and constraints can live and be enforced. An example of such rules could be dependency graphs.



 Comments   
Comment by Alex Neben [ 01/Dec/22 ]

I moved the work of actually doing this as part of clang-tidy into SERVER-71770 and am leaving this open for us to figure out a better way to do this. 

Comment by Jordi Serra Torrens [ 01/Dec/22 ]

alexander.neben@mongodb.com CollectionShardingRuntime is something we only want to be used within the sharding mongod code (mongo/db/s/).

Comment by Alex Neben [ 01/Dec/22 ]

jordi.serra-torrens@mongodb.com I am not super familiar with CollectionSharingRuntime. Is this something that we are trying to deprecate and we want to guard against future uses? Or is this something that we only want to use in a specific areas of the code?

Here is another way to think about this.
Do you want to have to add a suppression each time this is used? Or do you have a finite number of uses and just want to suppress warning against the existing ones to prevent new uses? 

Generated at Thu Feb 08 06:15:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.