feat (Unity): Updated options

docs/platforms/unity/configuration/options/cli-options/index.mdx

@@ -0,0 +1,65 @@
+---
+title: Sentry CLI Options
+description: "Learn more about how to configure the options used by Sentry CLI."
+sidebar_order: 30
+---
+
+The Unity SDK includes [Sentry CLI](/product/cli/) as a tool to upload debug symbols to Sentry. These debug symbols are used in processing events sent to Sentry to provide stacktraces and linenumbers. This page describes the options available to configure the Sentry CLI.
+
+## Programmatic Configuration
+
+Similar to the [programmatic configuration](/platforms/unity/configuration/options/programmatic-configuration/) of the SDK itself, the debug symbol upload via Sentry CLI also supports programmatic configuration.
+
+![Options Configuration](./img/sentry-cli-option-configuration.png)
+
+The `Configure` callback gets invoked during the build process and allows you to modify the options used by Sentry CLI.
+
+## Sentry CLI Options
+
+<ConfigKey name="upload-symbols" supported={["dotnet"]}>
+
+Whether the SDK should automatically upload debug symbols to Sentry. This requires a valid auth token, organization, and project.
+
+</ConfigKey>
+
+<ConfigKey name="upload-development-symbols" supported={["dotnet"]}>
+
+Whether the SDK should automatically upload debug symbols to Sentry for development builds.
+
+</ConfigKey>
+
+<ConfigKey name="upload-sources" supported={["dotnet"]}>
+
+Whether the SDK should automatically upload sources to Sentry; this enables Sentry to provide source-context on events.
+
+</ConfigKey>
+
+<ConfigKey name="url-override" supported={["dotnet"]}>
+
+This option allows you to override the default Sentry URL in case you are using a self-hosted Sentry instance or a custom domain.
+
+</ConfigKey>
+
+<ConfigKey name="auth" supported={["dotnet"]}>
+
+The auth token to use when uploading symbols to Sentry.
+
+</ConfigKey>
+
+<ConfigKey name="organization" supported={["dotnet"]}>
+
+The organization to use when uploading symbols to Sentry.
+
+</ConfigKey>
+
+<ConfigKey name="project" supported={["dotnet"]}>
+
+The project to use when uploading symbols to Sentry.
+
+</ConfigKey>
+
+<ConfigKey name="ignore-cli-errors" supported={["dotnet"]}>
+
+If set to true, the Sentry CLI will not exit with an error code if it encounters an error. **BE AWARE** you might have unminified/unsymbolicated crashes in production if the debug symbol upload fails. When using this flag, you should store built sourcemaps and debug files, to re-run the upload symbols command at a later point.
+
+</ConfigKey>

docs/platforms/unity/configuration/options.mdx → docs/platforms/unity/configuration/options/index.mdx

@@ -4,7 +4,9 @@ sidebar_order: 1
 description: "Learn more about how the SDK can be configured via options. These are being passed to the init function and therefore set when the SDK is first initialized."
 ---
 
-<PlatformContent includePath="configuration/config-intro" />
+## Programmatic Configuration
+
+The SDK provides a configuration window that allows you to set most of Sentry's options directly in the Unity Editor. Some options, like the `BeforeSend` callback, can only be set programmatically. Take a look at our documentation about <PlatformLink to="/configuration/options/programmatic-configuration/"> how to configure the SDK programmatically</PlatformLink> for more information.
 
 ## Core Options
 

docs/platforms/unity/configuration/options/programmatic-configuration/index.mdx

@@ -0,0 +1,64 @@
+---
+title: Programmatic Configuration
+description: "Learn more about how to configure the Unity SDK programmatically."
+sidebar_order: 20
+---
+
+We've added `Sentry Options Configuration` to the `Options Config` tab in the Sentry editor window to provide a way to modify options programmatically.
+
+![Options Configuration](./img/unity-options-configuration.png)
+
+## Programmatic Configuration
+
+The Sentry SDK for Unity includes [platform-specific (that is, Native)](/platforms/unity/native-support/) SDKs, such as [Android](/platforms/android/), [Apple](/platforms/apple/guides/ios/), and [Native](/platforms/native/) to provide native crash suppport. These SDKs share the options with which they get initialized.
+
+The C# layer self-initializes through the use of the [SubsystemRegistration RuntimeInitializeOnLoadMethodAttribute](https://docs.unity3d.com/ScriptReference/RuntimeInitializeLoadType.SubsystemRegistration.html).
+
+![Flow of initialization](./img/initialization-flow.png)
+
+If provided, the `Option Configuration Script` is executed on each app startup. The options are first used to initialize the native SDKs, then the managed (C#) SDK. This means that the options you set in your `Configure` callback will also apply on the native layer. For example:
+
+```csharp
+public override void Configure(SentryUnityOptions options)
+{
+    // BeforeSend is currently limited to C# code. Native errors - such as crashes in C/C++ code - are getting
+    // captured by the native SDKs, but the native SDKs won't invoke this callback.
+    options.SetBeforeSend((sentryEvent, _) =>
+    {
+        if (sentryEvent.Tags.ContainsKey("SomeTag"))
+        {
+            // Don't send events with a tag "SomeTag" to Sentry
+            return null;
+        }
+
+        return sentryEvent;
+    });
+
+    // Native SDK initialization timing options:
+    // Build-time initialization:
+    //   + Can capture Unity engine errors
+    //   - Options are fixed at build time
+    // Runtime initialization:
+    //   + Allows dynamic configuration
+    //   - May miss some early errors
+#if UNITY_ANDROID
+    options.AndroidNativeInitializationType = NativeInitializationType.Runtime;
+#elif UNITY_IOS
+    options.IosNativeInitializationType = NativeInitializationType.Runtime;
+#endif
+}
+```
+
+### Initialize Native SDKs first when targeting iOS or Android
+
+On mobile, the Unity SDK automatically modifies the generated Xcode and Gradle project to also contain the Cocoa and Java SDK respectively. These SDKs are capable of self-initializing before the Unity engine itself is started. This allows us to capture bugs/crashes happening within the engine itself.
+There are two initialization types:
+
+- `NativeInitializationType.Runtime`: Native SDKs initialize during runtime alongside the C# SDK
+- `NativeInitializationType.BuildTime`: Native SDKs initialize before Unity engine starts
+
+### Runtime Initialization (Default)
+With runtime initialization, the native SDKs are initialized at runtime alongside the C# SDK. This allows all options to be dynamically configured through C# code during execution.
+
+### Build Time Initialization
+When using build time initialization, the native SDKs are configured during build time and initialize before the Unity engine starts. This means the options are baked into the outputted projects and cannot be modified at runtime via C# code. Changes to properties like `Release` and `Environment` will not apply to events generated by the native SDKs.

docs/platforms/unity/migration/index.mdx

@@ -4,6 +4,20 @@ description: "Learn more about migrating to the current version."
 sidebar_order: 8000
 ---
 
+## Migrating to 3.0.0
+
+### Changes to the initialization behaviour on iOS and Android
+
+The native layer on mobile platforms (iOS and Android) no longer self-initializes before the Unity game engine starts. Previously, the SDK would use the options at build-time and bake them into the native layer. Instead, the SDK will now take the options passed into the Configure callback and use those to initialize the native SDKs. This allows users to modify the native SDK's options at runtime programmatically. The initialization behaviour is controlled by the `IosNativeInitializationType` and `AndroidNativeInitializationType` options.
+
+To restore the previous behaviour, you can set the `IosNativeInitializationType` and `AndroidNativeInitializationType` options to `BuildTime`.
+
+### Changes to the programmatic configuration
+
+The Runtime- and BuildTime-Configuration have been merged into a single OptionsConfiguration script. This allows for programmatic configuration of the SDK in one place using preprocessor directives instead of having to duplicate setting options in two different files.
+
+You can still use the old configuration classes, but they have been deprecated and will be removed in a future version. Going forward, you should use the new OptionsConfiguration script and make use of the preprocessor directives when setting options for different platforms.
+
 ## Migrating to 0.28.0
 
 ### Breaking Changes