Restore copyright + wire in build-time values

[ZacSweers]

No description provided.

[github-actions]

1. Use a consistent code style throughout the project. In the provided code, there are inconsistencies in the use of spaces around operators and parentheses. For example, in some places, there are spaces around the dot operator, while in other places, there are no spaces. It is recommended to follow a consistent code style to improve readability and maintainability.

2. Use meaningful variable and function names. In the provided code, there are variables and functions with names like ktfmtVersion, externalFiles, copyVersionTemplatesProvider, etc. These names are not descriptive and do not convey the purpose or intent of the variables or functions. It is recommended to use meaningful names that accurately describe the purpose or intent of the variables and functions.

3. Avoid using magic numbers or strings. In the provided code, there are magic strings like "SkateErrorHandler", "src/**/*.kt", "**/spotless.kt", etc. These magic strings can be hard to understand and maintain. It is recommended to use constants or variables with meaningful names to represent these values.

4. Use Kotlin idiomatic syntax and features. In the provided code, there are places where the code can be simplified or improved using Kotlin's idiomatic syntax and features. For example, instead of using toTypedArray(), you can use the spread operator (*) to pass a list as varargs. Instead of using listOf("SkateErrorHandler").map { "src/**/$it.kt" }, you can directly use listOf("src/**/*.kt"). These improvements can make the code more concise and readable.

5. Use proper exception handling. In the SkateErrorHandler class, there is a catch-all catch (e: Exception) block. It is recommended to catch specific exceptions and handle them appropriately. Catching all exceptions can make it difficult to identify and handle specific exceptions.

6. Use dependency injection instead of hardcoding dependencies. In the SkateErrorHandler class, the Bugsnag instance is created directly in the constructor. It is recommended to use dependency injection to provide the Bugsnag instance to the class. This can make the class more flexible and testable.

7. Separate concerns and responsibilities. In the SkateErrorHandler class, there is a mix of error reporting logic and UI-related code. It is recommended to separate these concerns into separate classes or functions. This can improve the readability and maintainability of the code.

8. Use proper access modifiers. In the Version.kt file, the VERSION, BUGSNAG_KEY, and GIT_SHA constants are declared as internal. It is recommended to use the appropriate access modifier based on the intended visibility of these constants. If they are intended to be used only within the same module, internal is appropriate. If they are intended to be used outside the module, public or private may be more appropriate.

9. Use proper exception handling in the copyVersionTemplatesProvider task. In the copyVersionTemplatesProvider task, there is no exception handling for potential errors during the file copy operation. It is recommended to handle exceptions and provide appropriate error messages or fallback behavior in case of errors.

10. Use proper error handling in the SkateErrorHandler class. In the SkateErrorHandler class, there is no error handling for potential errors during the error reporting process. It is recommended to handle errors and provide appropriate error messages or fallback behavior in case of errors.

To address these issues, here are some specific changes that can be made:

1. Use a consistent code style throughout the project. For example, use spaces around operators and parentheses consistently.

2. Use meaningful variable and function names. For example, instead of ktfmtVersion, use kotlinFormatterVersion. Instead of externalFiles, use skatePluginSourceFiles.

3. Avoid using magic numbers or strings. For example, instead of "SkateErrorHandler", use a constant like SKATE_ERROR_HANDLER_FILE_NAME. Instead of "src/**/*.kt", use a constant like SKATE_PLUGIN_SOURCE_FILES_PATTERN.

4. Use Kotlin idiomatic syntax and features. For example, instead of listOf("SkateErrorHandler").map { "src/**/$it.kt" }, use listOf("src/**/*.kt"). Instead of targetExclude("**/spotless.kt", "**/Aliases.kt", *externalFiles.toTypedArray()), use targetExclude("**/spotless.kt", "**/Aliases.kt", *externalFiles).

5. Use proper exception handling. Catch specific exceptions and handle them appropriately. For example, instead of catch (e: Exception), catch specific exceptions like catch (e: IOException) or catch (e: FileNotFoundException).

6. Use dependency injection instead of hardcoding dependencies. Instead of creating a Bugsnag instance directly in the constructor, provide it as a constructor parameter or use a dependency injection framework.

7. Separate concerns and responsibilities. Extract UI-related code into separate classes or functions. For example, create a separate class for UI-related code and use it in the SkateErrorHandler class.

8. Use proper access modifiers. Use the appropriate access modifier for constants based on their intended visibility. For example, if VERSION is intended to be used only within the same module, use internal. If it is intended to be used outside the module, use public or private.

9. Use proper exception handling in the copyVersionTemplatesProvider task. Add exception handling code to handle potential errors during the file copy operation. For example, use a try-catch block and provide appropriate error messages or fallback behavior in case of errors.

10. Use proper error handling in the SkateErrorHandler class. Add error handling code to handle potential errors during the error reporting process. For example, use a try-catch block and provide appropriate error messages or fallback behavior in case of errors.