[Epic] [v2.0] Refactor Integration Get*Settings to use Dedicated Structs

Overview

As discussed in !2670 (merged) , we are moving away from the generic Integration struct for service-specific settings. The current approach, using a generic struct, forces users to handle map[string]any the properties field, leading to poor Developer Experience (DX) and a lack of type safety.

This Epic tracks the refactoring of all Get*Settings endpoints to return integration-specific structs (e.g., HarborIntegration, JiraIntegration) that embed the base Integration struct.

Proposed Strategy

To balance velocity with review capacity during the v2.0 window (and the current Hackathon), I propose batching these refactors by domain rather than opening 50+ individual MRs. This ensures a more manageable review process for maintainers and keeps the repository history clean.

Batched Implementation Plan

Batch

Domain

Integrations Included

Status

0

Reference

Harbor (Pattern defined in !2670 (merged))

 Done

1

High Priority

Jira , Microsoft Teams, Slack

📋 Planned

2

Chat & Notify

Discord, Telegram, Mattermost, Matrix, Google Chat

📋 Planned

3

CI/CD & Monitoring

 Buildkite, Drone CI, TeamCity, Datadog, Prometheus

📋 Planned

4

Issue Trackers

 Bugzilla, Redmine, Asana, ClickUp, YouTrack

📋 Planned

5

Utilities

 Emails on Push, Pipeline Status Emails, Slash Commands

📋 Planned

Proposed Pattern

Each implementation will follow the pattern established in the Harbor MR:

  1. Define a specific ServiceIntegration struct embedding Integration.
  2. Define a typed ServiceIntegrationProperties struct.
  3. Update GetProjectServiceSettings and GetGroupServiceSettings return signatures.
  4. Update interface definitions and regenerate mocks.

Maintainer Feedback Requested

@timofurrer @PatrickRice @heidi.berry — Before I proceed with creating the individual batch issues:

  1. Does this batched approach work better for your review bandwidth compared to individual issues/MRs?
  2. Are there specific integrations you would like to see prioritized for the 2.0 release?
  3. For integrations with missing/unclear API documentation for properties, do you prefer we use map[string]any as a placeholder or wait for further research?
Edited by Hamza Hassanain