Use nested structure to organize CI classes
Problem
Today classes related to CI domain under app/
are mostly organized in a flat structure. This organization makes it hard to understand the domain because:
- It's not clear what are all the main components
- It's not clear whether a component has private or sub components
- It's hard to enforce boundaries to decouple components when we don't know (1) and (2)
Proposal
Following on #207480 (closed) I propose we organize our classes in a tree structure by nesting components when:
- They are private to the top level component (e.g. see
build/metadata.rb
) - They are specific types of the top level component (e.g. see
variable/job_variable.rb
) - They extend functionality of the top level component (e.g. see
pipeline/schedule.rb
)
app/models/ci
- bridge
- build
- build/metadata
- build/need
- build/runner_session
- build/trace
- build/trace/chunk
- build/trace/section
- build/trace/section_name
- group
- job_artifact
- job_artifact/blob
- persistent_ref
- pipeline
- pipeline/persistent_ref
- pipeline/chat_data
- pipeline/config
- pipeline/enums
- pipeline/schedule
- processable
- ref
- resource_group
- resource
- runner
- runner/runner_namespace
- runner/runner_project
- stage
- trigger
- trigger/request
- variable
- variable/pipeline_schedule_variable
- variable/pipeline_variable
- variable/group_variable
- variable/job_variable
The following principle could be applied to other directories: services
, finders
, serializers
, etc.