Обновления #53
Обновления #53
Conversation
- обновлен gradle - jdk17 - публикация в сонатайп - minor fixes
WalkthroughThe project has embraced more recent Java versions, discarding Java 11 in favor of Java 17 and 20, and updated various plugins and dependencies to newer versions. The build automation has been enhanced with workflows for Sonatype publishing and release management. Gradle itself has been upgraded to version 8.5. A Java record now replaces a Lombok annotated class, reflecting a shift towards native language features for immutability. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files ignored due to path filters (2)
gradle/wrapper/gradle-wrapper.jaris excluded by:!**/*.jarsrc/main/resources/log4j.xmlis excluded by:!**/*.xml
Files selected for processing (7)
- .github/workflows/check.yml (1 hunks)
- .github/workflows/publish-to-sonatype.yml (1 hunks)
- .github/workflows/release.yml (1 hunks)
- build.gradle.kts (4 hunks)
- gradle/wrapper/gradle-wrapper.properties (1 hunks)
- gradlew (3 hunks)
- src/main/java/com/github/_1c_syntax/bsl/supconf/SupportConfiguration.java (3 hunks)
Files skipped from review due to trivial changes (2)
- .github/workflows/check.yml
- gradle/wrapper/gradle-wrapper.properties
Additional comments: 12
.github/workflows/release.yml (1)
- 17-17: The Java version has been updated to 17, which is consistent with the project's transition to JDK 17. Ensure that all other workflow steps and actions are compatible with Java 17.
.github/workflows/publish-to-sonatype.yml (1)
- 19-20: The Java version has been updated to 17 with the distribution set to 'liberica'. Verify that the 'liberica' distribution is compatible with all steps in this workflow, especially the publishing process to Sonatype.
Verification successful
The output from the shell script indicates that the 'liberica' distribution is specified in the
.github/workflows/publish-to-sonatype.ymlfile. However, to verify compatibility, we would need to check if there are any steps within the workflow that might not be compatible with the 'liberica' distribution. This could involve checking for any specific JDK distribution requirements in the steps that publish to Sonatype or any other JDK-dependent steps in the workflow.Since the shell script only confirms the presence of 'liberica' in the workflow file and does not provide information on compatibility, further verification is needed.
This script will search for the steps in the
publish-to-sonatype.ymlworkflow that use theactions/setup-javaaction, which is where the JDK distribution is set, and will provide some context around those steps to help determine if there's any indication of incompatibility with 'liberica'.
The output from the script shows that the 'liberica' distribution is set up for JDK 17 in the
publish-to-sonatype.ymlworkflow file, and the next step is "Publish to Sonatype". There is no output indicating any specific requirements or potential incompatibilities with the 'liberica' distribution in the steps following the JDK setup.Given this information, there is no evidence from the workflow file to suggest that the 'liberica' distribution is incompatible with the steps in the workflow, particularly the publishing process to Sonatype. Therefore, based on the available data, the review comment concerning the compatibility of the 'liberica' distribution with all steps in this workflow, especially the publishing process to Sonatype, has been verified and no issues have been found.
Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that 'liberica' distribution is available and compatible with the workflow rg --files-with-matches "distribution: 'liberica'" .github/workflows/*.ymlLength of output: 225
Script:
#!/bin/bash # Check for any steps that might require a specific JDK distribution or might not be compatible with 'liberica' rg "steps:" -A 20 .github/workflows/publish-to-sonatype.yml | rg -B 1 -A 4 "uses: actions/setup-java"Length of output: 272
src/main/java/com/github/_1c_syntax/bsl/supconf/SupportConfiguration.java (2)
31-32: The class has been refactored to a Java record, which is a more concise and appropriate structure for immutable data carriers in Java 17. This change should simplify the code and reduce boilerplate.
41-41: The
compareTomethod has been updated. Ensure that this change does not affect the ordering logic in any parts of the application whereSupportConfigurationinstances are compared.Verification successful
The search for explicit usages of the
compareTomethod within theSupportConfigurationclass did not yield any results, which suggests that there are no custom implementations ofcompareTowithin that class other than the one defined in theSupportConfigurationitself.The second script, however, found multiple references to the
compareTomethod within theSupportConfiguration.javafile, indicating where the method is used within the class. It also found references in theSupportConfigurationTest.javaandParseSupportDataTest.javafiles, which likely contain tests that verify the behavior of thecompareTomethod.Given these findings, it seems that the
compareTomethod is indeed used within theSupportConfigurationclass and is also part of tests to ensure its correct behavior. Therefore, the review comment is valid in that any changes to thecompareTomethod should be carefully reviewed to ensure they do not affect the ordering logic whereSupportConfigurationinstances are compared.The tests found in
SupportConfigurationTest.javaandParseSupportDataTest.javashould be sufficient to verify that the changes to thecompareTomethod have not broken the expected behavior, assuming these tests are comprehensive and correctly implemented.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usages of SupportConfiguration's compareTo method to ensure the logic is still valid. ast-grep --lang java --pattern $'class $_ { $$$ compareTo($_, $_) { $$$ } $$$ }'Length of output: 81
Script:
#!/bin/bash # Search for explicit usages of the compareTo method within the SupportConfiguration class ast-grep --lang java --pattern $'class SupportConfiguration { $$$ compareTo($_, $_) { $$$ } $$$ }'Length of output: 99
Script:
#!/bin/bash # Additionally, search for any potential references to the compareTo method in the entire codebase rg "compareTo" --type javaLength of output: 996
build.gradle.kts (5)
8-17: Plugin versions have been updated. Verify that these new versions are compatible with each other and with the project's Gradle version.
36-36: The
isSnapshotvariable is set based on the Git reference type. Ensure that this logic correctly identifies snapshot versions, especially in CI/CD pipelines where versioning is critical.Verification successful
The
isSnapshotvariable inbuild.gradle.ktsis used to determine whether the current build is a snapshot or a release. The logic for settingisSnapshotis based on the Git reference type, and it is used to configure the repository URL for publishing and the version naming. The provided context shows that if the build is a snapshot, it is published to a snapshot repository, and the version name is suffixed with "-SNAPSHOT". This is consistent with standard Maven versioning practices. The usage ofisSnapshotappears to be correct for the purposes of versioning and publishing in CI/CD pipelines.* 62-63: Java source and target compatibility have been set to version 17, which should be consistent with the project's transition to JDK 17. Confirm that all source code is compatible with Java 17.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for the usage of isSnapshot in the build script to ensure it's being used correctly. rg "isSnapshot" build.gradle.ktsLength of output: 213
Script:
#!/bin/bash # Extract the surrounding context for the second and third occurrences of `isSnapshot` to understand its usage. rg -C 5 "isSnapshot" build.gradle.ktsLength of output: 1089
126-148: The
mavenpublication's versioning logic has been updated. Verify that the new logic correctly sets the version for snapshots and releases, and that it aligns with the project's versioning strategy.199-202: A new
nexusStagingblock has been added with configuration details for Sonatype publishing. Ensure that theserverUrlandstagingProfileIdare correct and that they correspond to the project's Sonatype repository settings.gradlew (3)
87-87: The handling of the
APP_HOMEvariable has been modified to discard standard output. This is a minor change but verify that it does not affect the execution of the Gradle wrapper in any environments.148-156: The script disables specific shellcheck warnings. Confirm that these changes are intentional and that they do not introduce any issues with script execution on different platforms.
205-209: The script has been modified to collect JVM options. Ensure that these changes do not affect the JVM options passed to Gradle in various environments, especially with regards to memory settings and other critical JVM arguments.
Verification successful
The review of the
gradlewscript and the context provided from the shell script outputs indicate that theDEFAULT_JVM_OPTSare explicitly defined and included in the Java command arguments. The script's comments and theevalcommand usage suggest that the handling of JVM options, including memory settings, is preserved with the addition of explicit escaping of shell fragments. There is no evidence from the provided context that the changes to the script would negatively affect the JVM options passed to Gradle in various environments.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that the JVM options collection does not affect critical JVM arguments. rg "DEFAULT_JVM_OPTS" gradlewLength of output: 403
Script:
#!/bin/bash # Check the previous behavior of DEFAULT_JVM_OPTS and how it was used in the script before the changes. rg "DEFAULT_JVM_OPTS" gradlew -B 3 -A 3Length of output: 1367
Описание
Связанные задачи
Closes:
Чеклист
Общие
gradlew precommit)Дополнительно
Summary by CodeRabbit
New Features
Improvements
Refactor
SupportConfigurationfrom a Lombok class to a Java record for cleaner and more concise code.Bug Fixes
compareTomethod formatting within theSupportConfigurationrecord.