Set functions to modify ScriptableSentryUnityOptions from internal to public

[RiederAlex]

Set functions to modify ScriptableSentryUnityOptions from internal to public

Why?
Unity projects quickly outgrow the features provided by the default "Build" and "Build and run".
What ends up happening is that Unity users begin to script their builds from within via C#, which includes automated changing of various values for scriptable objects - think of information like branch/commithash/timestamp - that should be included in the game, but are only known during buildtime.

This pull requests make this possible for ScriptableSentryUnityOptions, to e.g. set the environment/release per branch or different dsn for production/development.

[bitsandfoxes]

Hey, thanks for opening this up. If I catch your intention: You want to programmatically modify the scriptable options object instead of using the programmatic initialization approach? Are there any features in particular you are missing?
As a workaround to unblock right now you you could overwrite the actual text inside the option.asset

[RiederAlex]

Yes, the point being that this happens during player build-time, not during runtime!

To rephrase it bit differently: The CI I'm currently working with calls an editor-only C# function, which does a bunch of stuff before building the player via BuildPipeline.BuildPlayer. A bunch of stuff in this case is things like injecting commit id/branch and including/excluding certain scenes. This works by changing the scriptable object(s) referenced in the project and then saving the asset again before building the player, so it gets included into the build.

[bitsandfoxes]

While we do see your point and the use-case we're reluctant to just merge this.
For example: We read from the scriptable object during different times, i.e. IPostGenerateGradleAndroidProject.OnPostGenerateGradleAndroidProject for Android or OnPostProcessBuild for iOS. So if the scriptable object was just public we'd have no way of knowing that it changed and we could end up with settings not making it into the build.
Do you see an alternative solution?
We thought about maybe platform-sensitive settings, a bit like the build settings themselves with the option to override specific ones. Or multiple scriptable objects that get flagged for platforms.

[RiederAlex]

I've looked at the code and the hooks you mentioned remain unaffected by this change, as what I want to achieve is happening before these get executed.

So basically it is: <MyStaticC#FunctionWhichPreparesTheBuild> -> BuildPipeline.BuildPlayer (which calls OnPostGenerateGradleAndroidProject/OnPostProcessBuild) -> <MyStaticC#FunctionWhichPreparesTheBuild>
The changes to the scriptable object would happen in the first part, before the BuildPlayer call is made.

Platform-sensitive settings would allow some more flexibility compared to the current system, but
it would still be impossible to have a different environment/dsn per some arbitary settings your SDK does not know of :)

I would also personally advise against going too far in this direction (regarding allowing of configurating everything per platform via the UI), as the simplicity is one of my favorite aspects of this great SDK/product!

[bruno-garcia]

I've looked at the code and the hooks you mentioned remain unaffected by this change, as what I want to achieve is happening before these get executed.

Sounds like there's no other reason to keep them private? Surely they can be modified outside of our code which includes validations etc, but at that point "You must know what you're doing".

[bruno-garcia]

We wanted to collect requirements for changes y'all do in such way to perhaps offer first class features to allow those. By making it public it makes it less likely for users to reach out with such requirements. But we can live with that

[bitsandfoxes]

Hi @RiederAlex! Would it be possible for you to rebase this fork onto main? Or pull main into it so we can let CI pass and then merge it?
Thanks a lot!

[bitsandfoxes]

Hey @RiederAlex, I took the liberty of just merging your PR so your contributions would make it into the 0.8.0 we just released. Thanks a lot for contributing!