docs: Add integrations documentation to developer-docs section

[itaybre]

Moving these docs from Notion to Github.

Opinions on Notion

@itaybre:
I believe the option 3 (automated releases from sentry-cocoa) is the way forward because at this moment our biggest constraint are the man hours, adding more workload for us is not going to help us as a team, and once the set up is ready, we shouldn’t need to maintain the release workflow, all with having the best solution of users which is only importing the integration they need.

If going with a repo per integration, repo name scheme:

sentry-cocoa-*<yourfavoriteloggingframework>*

If going with a repo per integration type, repo name scheme:

sentry-cocoa-<integration-type>

@philprime
I believe the option 3 (package-mirror) is the best way, using GitHub workflows to automatically update the downstream packages and tags accordingly. As the integrations are still tightly coupled with the main SDK code, we should keep the code and documentation close to each other. Asking users to add an additional dependency to their project is a good trade-off compared to having to download unnecessary ones (also impacts their CI workflows, e.g. longer download times cause more CI build minutes, cause more costs)

@philipphofmann
I’m also for option 3 because all the code lives in one place, and we only need to use multiple repositories because of Apple's ecosystem package manager limitations. That limitation shouldn’t force us to split up the code across multiple repositories. We should abstract that away as much as we can from the codebase if possible, and that is what option 3 is about.

Steps forward:

• Align repository on name structure
• Talk with GitHub admins to find the best way to securely deploy to other repositories
• Create Repositories for SwiftLog
  • Initial releases will probably be manual
• Create integrations project in sentry-cocoa
  • Create a CI template for integrations to run in an isolated context

Closes #6903

[denrase]

@itaybre We also got this suggestions to use package traits. There dependencies can also be defined as optional. Glanced over it and it uses conditional compilation in the codebase, but I'm not sure this will play out with our approach to offer pre-compiled artefacts in SPM?

https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/packagetraits/

Maybe worth considering it though, if not for the main Package.swift, then maybe for a downstream sentry-cocoa-integrations Package.swift, as we'd also fetch multiple dependencies, even thou a user is only interested in integrating one sentry log integration.

For example, swift-configuration has a trait for a swift-log integration.

.trait(
    name: "LoggingSupport",
    description: "Adds support for swift-log integration."
),

...

.product(
    name: "Logging",
    package: "swift-log",
    condition: .when(traits: ["LoggingSupport"])
),

[itaybre]

@itaybre We also got this suggestions to use package traits. There dependencies can also be defined as optional. Glanced over it and it uses conditional compilation in the codebase, but I'm not sure this will play out with our approach to offer pre-compiled artefacts in SPM?

https://docs.swift.org/swiftpm/documentation/packagemanagerdocs/packagetraits/

Maybe worth considering it though, if not for the main Package.swift, then maybe for a downstream sentry-cocoa-integrations Package.swift, as we'd also fetch multiple dependencies, even thou a user is only interested in integrating one sentry log integration.

For example, swift-configuration has a trait for a swift-log integration.

.trait(
    name: "LoggingSupport",
    description: "Adds support for swift-log integration."
),

...

.product(
    name: "Logging",
    package: "swift-log",
    condition: .when(traits: ["LoggingSupport"])
),

Looks like traits are only supported in Swift 6.1+

[philipphofmann]

I would rename the file to 3rd-party-integrations or something similar, otherwise you could confuse it with the SentryIntegrations in the code such as SentryCrashIntegration, ...

I would only mention the chosen approach in the Integrations.md. I think you could add the discussed approaches and the pros and cons to the https://github.com/getsentry/sentry-cocoa/blob/main/develop-docs/DECISIONS.md.

[philipphofmann]

LGTM, good enough for a start. We will update this as we go. Thanks @itaybre