Development: Remove jenkins client and access Jenkins REST API directly
#10084
Conversation
also exclude a few now unused dependencies try out RestClient instead of RestTemplate for Apollon
github-actions
bot
added
tests
server
github-actions
bot
added
the
lecture
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
krusche
temporarily deployed
to
artemis-test5.artemis.cit.tum.de
GitHub Actions
Inactive
github-actions
bot
added
the
config-change
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java
Dismissed
Show dismissed
Hide dismissed
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java
Dismissed
Show dismissed
Hide dismissed
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsEndpoints.java
Outdated
Show resolved
Hide resolved
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.java
Outdated
Show resolved
Hide resolved
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java
Outdated
Show resolved
Hide resolved
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
|
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 pmd (7.8.0)src/main/java/de/tum/cit/aet/artemis/core/config/Constants.javaThe following rules are missing or misspelled in your ruleset file category/vm/bestpractices.xml: BooleanInstantiation, DontImportJavaLang, DuplicateImports, EmptyFinallyBlock, EmptyIfStmt, EmptyInitializer, EmptyStatementBlock, EmptyStatementNotInLoop, EmptySwitchStatements, EmptySynchronizedBlock, EmptyTryBlock, EmptyWhileStmt, ExcessiveClassLength, ExcessiveMethodLength, ImportFromSamePackage, MissingBreakInSwitch, SimplifyBooleanAssertion. Please check your ruleset configuration. src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.javaThe following rules are missing or misspelled in your ruleset file category/vm/bestpractices.xml: BooleanInstantiation, DontImportJavaLang, DuplicateImports, EmptyFinallyBlock, EmptyIfStmt, EmptyInitializer, EmptyStatementBlock, EmptyStatementNotInLoop, EmptySwitchStatements, EmptySynchronizedBlock, EmptyTryBlock, EmptyWhileStmt, ExcessiveClassLength, ExcessiveMethodLength, ImportFromSamePackage, MissingBreakInSwitch, SimplifyBooleanAssertion. Please check your ruleset configuration. src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.javaThe following rules are missing or misspelled in your ruleset file category/vm/bestpractices.xml: BooleanInstantiation, DontImportJavaLang, DuplicateImports, EmptyFinallyBlock, EmptyIfStmt, EmptyInitializer, EmptyStatementBlock, EmptyStatementNotInLoop, EmptySwitchStatements, EmptySynchronizedBlock, EmptyTryBlock, EmptyWhileStmt, ExcessiveClassLength, ExcessiveMethodLength, ImportFromSamePackage, MissingBreakInSwitch, SimplifyBooleanAssertion. Please check your ruleset configuration.
WalkthroughThis pull request introduces comprehensive changes across multiple files, primarily focusing on dependency management, configuration updates, and refactoring of Jenkins-related services and test classes. The modifications include adding new dependencies in Changes
Suggested labels
Suggested reviewers
Possibly related PRs
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 using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (22)
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.java (1)
33-33: Consider handling empty or whitespace XML inputs.Adding
@NotNullensures thatxmlStringwon't be null, but it might still be empty or contain only whitespace. Consider handling or asserting that the input is not empty if parsing an empty string is invalid in your use cases.src/test/java/de/tum/cit/aet/artemis/programming/ContinuousIntegrationTestService.java (1)
172-172: Avoid redundant assertions
This line explicitly asserts equality ofhealth.additionalInfo().get("url")withciServerUrl, but the subsequent assertion (containsEntry("url", ciServerUrl)) verifies the same.You can remove this direct equality check or the subsequent one to reduce redundancy:
-assertThat(health.additionalInfo().get("url")).isEqualTo(ciServerUrl); assertThat(health.additionalInfo()).containsEntry("url", ciServerUrl);src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsAuthorizationInterceptorTest.java (1)
119-119: Extract hardcoded path segment to a constant.Using
'crumbIssuer/api/json'inline is acceptable, but consider extracting it to a constant to make the path definition easier to maintain and more self-documenting in both production and test code.private void mockGetCrumb(String expectedBody, HttpStatus expectedStatus) throws URISyntaxException { - final var uri = UriComponentsBuilder.fromUri(jenkinsServerUri).pathSegment("crumbIssuer/api/json").build().toUri(); + final var CRUMB_API_PATH = "crumbIssuer/api/json"; + final var uri = UriComponentsBuilder.fromUri(jenkinsServerUri).pathSegment(CRUMB_API_PATH).build().toUri(); ... }src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionIntegrationTest.java (2)
396-396: Check for any leftover references to the old param.
Everything appears correct here; no further changes needed.
433-433: Consider a small refactor to reduce repetition.
If desired, you can abstract these repetitive mocking calls into a dedicated setup method.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseIntegrationJenkinsGitlabTest.java (2)
414-414: Redundant repeated call or missing context?
The repeated invocation ofmockCheckIfProjectExistsJobUrlEmptyOrNull(programmingExercise)may introduce unnecessary overhead if the scenarios are identical. Ensure each call is testing distinct functionality.
417-417: Clarify multiple consecutive identical mock calls.
Similar to line 414, consider unifying or documenting the rationale for multiple consecutive calls to the same mocking method.src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobServiceTest.java (2)
67-68: Mock Verification
Comment clarity is good: it highlights the expectation thatcreateJobshould not be called. Marking it explicitly here helps future maintainers quickly understand why the job creation is skipped.
92-92: Replacing IOException with JenkinsException
Switching toJenkinsExceptionfor XML error scenarios centralizes error handling in alignment with Jenkins-specific exceptions. This helps keep error types consistent across the service.src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java (2)
199-203: Potential duplication in folder job mocks.Calling
mockGetFolderJob(targetProjectKey, null)and then again callingmockGetFolderJob(targetProjectKey)within a few lines may be redundant or confusing. If these calls serve different logical purposes, consider renaming one of the method usages or adding explanatory comments to clarify their distinctions.
438-438: Minor improvement for clarity.The code calls
mockAddUsersToGroups(Set.of(group), failInCi)immediately after updating the VCS user. Ensure the group logic in Jenkins and GitLab is consistent when the user is first updated in GitLab, then assigned in Jenkins. Small commentary on the rationale would help future maintainers.src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsServiceTest.java (1)
164-167: Repeated code snippet.
You are invokingmockCopyBuildPlanFromTemplatefor both the template and solution build plan in the same manner. Consider abstracting this into a single helper method for better test readability.build.gradle (5)
263-263: Using HikariCP for JDBC connection pooling.
HikariCP is known for its performance. Ensure any existing pool configs (like inapplication*.yml) match recommended settings (max pool size, etc.).
266-266: Introducing commons-text and commons-math3.
These libraries are handy, but watch for potential overshadowing of Java SDK capabilities. Evaluate whether a smaller library set might suffice.
325-325: Bouncy Castle for extended cryptography capabilities.
Ensure that using Bouncy Castle is appropriate for your cryptographic needs and is permitted within your deployment environment.
334-334: ICU4J charset library included.
ICU4J may be large. If you only need limited locale/charset support, consider verifying minimal usage.
459-463: Gradle Lint rule configuration.
Using'dependency-parentheses'can clean up Gradle files. Consider enablingunused-dependencychecks once the codebase is stable.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsService.java (1)
170-171: Consider UriComponentsBuilder usage for building Jenkins URLs.
A string concatenation is done here, but the TODO suggests usingUriComponentsBuilder. Adopting it would enhance readability and reduce potential encoding issues.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanLinkInfoContributor.java (1)
24-24: Consider robust path construction.String concatenation can lead to subtle path issues (e.g., missing or duplicate slashes). Consider using
UriComponentsBuilderor a dedicated library function for safer path concatenation.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInfoContributor.java (1)
24-24: Build plan URL construction.Similar to other occurrences, consider a safer approach to join paths rather than relying on raw string concatenation.
src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.java (1)
17-17: Newly introduced request factory imports.Explicitly importing
ClientHttpRequestFactoryand related classes is fine; be mindful to keep usage minimal to promote readability.src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java (1)
Line range hint
1-2400: Consider breaking up this utility class into smaller dedicated classes.
The class is quite large, containing multiple test setup routines and scenario-based test helpers. Splitting it into more focused classes would improve maintainability and adhere to single-responsibility principles.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (6)
.idea/runConfigurations/Artemis__Server__LocalVC___Jenkins_.xmlis excluded by!**/*.xmllibs/jenkins-client-0.4.1.jaris excluded by!**/*.jar,!**/*.jarsrc/main/kubernetes/artemis/secrets/artemis-secrets.ymlis excluded by!**/*.ymlsrc/main/resources/config/application-artemis.ymlis excluded by!**/*.ymlsrc/main/resources/config/application.ymlis excluded by!**/*.ymlsrc/test/resources/config/application-artemis.ymlis excluded by!**/*.yml
📒 Files selected for processing (63)
build.gradle(11 hunks)src/main/java/de/tum/cit/aet/artemis/core/config/Constants.java(1 hunks)src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.java(5 hunks)src/main/java/de/tum/cit/aet/artemis/core/config/connector/JenkinsServerConfiguration.java(0 hunks)src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.java(3 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/InternalUrlService.java(1 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/aeolus/AeolusBuildPlanService.java(0 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/gitlab/GitLabPersonalAccessTokenManagementService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsAuthorizationInterceptor.java(4 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsEndpoints.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInfoContributor.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInternalUrlService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsResultService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsService.java(9 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsTriggerService.java(1 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsUserManagementService.java(8 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanCreator.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanLinkInfoContributor.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanService.java(11 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobPermissionsService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java(6 hunks)src/test/java/de/tum/cit/aet/artemis/core/authentication/InternalAuthenticationIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/core/authentication/UserJenkinsGitlabIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/core/connector/AeolusRequestMockProvider.java(3 hunks)src/test/java/de/tum/cit/aet/artemis/core/connector/GitlabRequestMockProvider.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.java(11 hunks)src/test/java/de/tum/cit/aet/artemis/core/service/TelemetryServiceTest.java(4 hunks)src/test/java/de/tum/cit/aet/artemis/core/user/AccountResourceWithGitLabIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exam/ExamIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exam/ExamParticipationIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exam/ExamUserIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exam/StudentExamIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exercise/participation/ParticipationIntegrationTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/exercise/service/ParticipationServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/lecture/LectureUnitServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/modeling/apollon/ApollonConversionServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/AbstractProgrammingIntegrationJenkinsGitlabTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ConsistencyCheckGitlabJenkinsIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ContinuousIntegrationTestService.java(3 hunks)src/test/java/de/tum/cit/aet/artemis/programming/CourseGitlabJenkinsIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseGitlabJenkinsIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseIntegrationJenkinsGitlabTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTemplateIntegrationTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionAndResultGitlabJenkinsIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionIntegrationTest.java(8 hunks)src/test/java/de/tum/cit/aet/artemis/programming/RepositoryProgrammingExerciseParticipationJenkinsIntegrationTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusBuildScriptGenerationServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusTemplateResourceTest.java(0 hunks)src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsAuthorizationInterceptorTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobPermissionServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobServiceTest.java(3 hunks)src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsServiceTest.java(8 hunks)src/test/java/de/tum/cit/aet/artemis/programming/util/MockDelegate.java(0 hunks)src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java(6 hunks)src/test/java/de/tum/cit/aet/artemis/shared/architecture/module/AbstractModuleRepositoryArchitectureTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationGitlabCIGitlabSamlTest.java(0 hunks)src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationIndependentTest.java(0 hunks)src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java(4 hunks)src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationLocalCILocalVCTest.java(0 hunks)
💤 Files with no reviewable changes (7)
- src/main/java/de/tum/cit/aet/artemis/programming/service/aeolus/AeolusBuildPlanService.java
- src/main/java/de/tum/cit/aet/artemis/core/config/connector/JenkinsServerConfiguration.java
- src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationIndependentTest.java
- src/test/java/de/tum/cit/aet/artemis/programming/util/MockDelegate.java
- src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusTemplateResourceTest.java
- src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationLocalCILocalVCTest.java
- src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationGitlabCIGitlabSamlTest.java
✅ Files skipped from review due to trivial changes (1)
- src/test/java/de/tum/cit/aet/artemis/exam/ExamParticipationIntegrationTest.java
🧰 Additional context used
📓 Path-based instructions (54)
src/main/java/de/tum/cit/aet/artemis/programming/service/InternalUrlService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/exam/ExamUserIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionAndResultGitlabJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobPermissionServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/gitlab/GitLabPersonalAccessTokenManagementService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseGitlabJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/user/AccountResourceWithGitLabIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsResultService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/AbstractProgrammingIntegrationJenkinsGitlabTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/core/config/Constants.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/core/connector/GitlabRequestMockProvider.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/connector/AeolusRequestMockProvider.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsAuthorizationInterceptorTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTemplateIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/authentication/InternalAuthenticationIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/exercise/service/ParticipationServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/lecture/LectureUnitServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsTriggerService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/ContinuousIntegrationTestService.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanCreator.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInternalUrlService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/core/service/TelemetryServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/modeling/apollon/ApollonConversionServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/authentication/UserJenkinsGitlabIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/exam/ExamIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/exam/StudentExamIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/RepositoryProgrammingExerciseParticipationJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsAuthorizationInterceptor.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/shared/architecture/module/AbstractModuleRepositoryArchitectureTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobPermissionsService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInfoContributor.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/CourseGitlabJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusBuildScriptGenerationServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseIntegrationJenkinsGitlabTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsUserManagementService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/exercise/participation/ParticipationIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanLinkInfoContributor.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/ConsistencyCheckGitlabJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsEndpoints.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
📓 Learnings (2)
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java (2)
Learnt from: magaupp
PR: ls1intum/Artemis#8802
File: src/main/java/de/tum/in/www1/artemis/service/connectors/jenkins/JenkinsProgrammingLanguageFeatureService.java:43-43
Timestamp: 2024-11-12T12:51:58.050Z
Learning: Jenkins support for Rust was added in commit d0fb7032e70c001dc8b2c4d0a391ca8bf7e7d586.
Learnt from: magaupp
PR: ls1intum/Artemis#9256
File: src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java:0-0
Timestamp: 2024-11-12T12:52:03.805Z
Learning: In `JenkinsProgrammingLanguageFeatureService.java`, comments explaining boolean flags in calls to the `ProgrammingLanguageFeature` constructor are unnecessary because the parameter names are clear, and most IDEs display them as inline hints.
src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java (2)
Learnt from: magaupp
PR: ls1intum/Artemis#9751
File: src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseFactory.java:143-148
Timestamp: 2024-11-26T20:43:17.588Z
Learning: In `src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseFactory.java`, the test package name assigned in `populateUnreleasedProgrammingExercise` does not need to adhere to naming conventions.
Learnt from: Hialus
PR: ls1intum/Artemis#7451
File: src/test/java/de/tum/in/www1/artemis/exercise/programmingexercise/ProgrammingExerciseTestService.java:9-9
Timestamp: 2024-11-12T12:51:58.050Z
Learning: The use of wildcard imports is acceptable in this project as specified in the `.editorconfig` file.
🔇 Additional comments (239)
src/test/java/de/tum/cit/aet/artemis/programming/CourseGitlabJenkinsIntegrationTest.java (1)
32-32: LGTM! Change aligns with Jenkins client removal.The simplification of the mock setup by removing the
jenkinsServerparameter is consistent with the PR's objective of migrating from Jenkins client to direct REST API usage. The change maintains test integrity while reducing dependencies.src/test/java/de/tum/cit/aet/artemis/core/user/AccountResourceWithGitLabIntegrationTest.java (1)
36-36: Double-check the impact of removingjenkinsServerfrom the mock setup.Be sure that omitting
jenkinsServerfromenableMockingOfRequestsdoesn’t break any tests that previously needed access to a mocked Jenkins server. If there are tests still depending on Jenkins server interactions, consider adding them here or adjusting the tests accordingly.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseGitlabJenkinsIntegrationTest.java (1)
55-55: Simplify Jenkins mocking approach
Removing thejenkinsServerparameter aligns with the objective of eliminating the Jenkins client and interacting directly via the Jenkins REST API. This looks good.src/test/java/de/tum/cit/aet/artemis/lecture/LectureUnitServiceTest.java (1)
Line range hint
47-51: Localizing thelecturevariable is a good practice to limit scope.Declaring
lecturewithininit()helps keep the test setup concise while preventing accidental usage in other tests. However, iflecturemust be referenced by other tests, consider refactoring to share it among relevant tests in a well-structured manner (e.g., through a common fixture in aBeforeEachmethod).src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusBuildScriptGenerationServiceTest.java (3)
35-35: Good job restricting the field’s visibility.Changing the field
restTemplatetoprivatebetter aligns with the principle of encapsulation and keeps the class’s internal state from being unintentionally exposed.
38-38: Consistent improvement of access modifiers.Using
privateforaeolusBuildPlanServicepromotes good design practices in tests by limiting direct external manipulation of the test dependencies.
41-41: Enhancing encapsulation.Setting
aeolusBuildScriptGenerationServiceto private is a solid step. It clarifies the scope of this test fixture, avoids external references, and keeps the test code tidy and consistent with recommended guidelines.src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusServiceTest.java (3)
51-51: Visibility change toprivateis a good encapsulation practice.
Keeping test class fields private ensures better encapsulation and clarity about their usage. No functional issues detected here.
57-57: Visibility change toprivateis consistent with best practices.
This is a straightforward refactoring that enhances encapsulation in test code. No concerns from a correctness or test maintainability viewpoint.
63-63: Visibility change toprivateis aligned with good encapsulation.
This change is consistent with the other fields. It improves test class design with no adverse impact on functionality.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.java (1)
63-65: Reaffirm the rationale for parsing into a Document.The comment correctly highlights that XML can vary due to arbitrary Jenkins plugin configs, making a single DTO approach impractical. The
@NotNullannotation further clarifies expectations for non-null XML content. This approach is appropriate given the variability of plugin configurations.src/test/java/de/tum/cit/aet/artemis/programming/ConsistencyCheckGitlabJenkinsIntegrationTest.java (1)
13-13: Ensure no references tojenkinsServerare missed.With the
jenkinsServerparameter removed, confirm that remaining references or usage ofjenkinsServerare fully removed or refactored.✅ Verification successful
No remaining references to
jenkinsServerfound in the codebaseThe search results show that all occurrences of "jenkinsServer" in the codebase are related to the
jenkinsServerUrivariable, which is a different entity than the removedjenkinsServerparameter. ThejenkinsServerUriis used to store and handle the URI/URL of the Jenkins server, while the removedjenkinsServerparameter was likely a service or configuration object.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that there are no lingering references to jenkinsServer in the test suite. rg -A 2 'jenkinsServer'Length of output: 27547
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTest.java (2)
53-53: Removed Jenkins server parameter is consistent with direct REST approach.This line change aligns with the PR's objective to remove explicit references to the Jenkins server and rely solely on the Jenkins REST API endpoints via the mock provider. No issues found with the approach.
174-174: Mocking approach is correctly streamlined here as well.Repeating the earlier pattern in the test ensures consistent mocking of Jenkins requests without the additional server parameter. Adheres to the updated design and appears valid.
src/test/java/de/tum/cit/aet/artemis/exam/StudentExamIntegrationTest.java (1)
274-274: Removal of thejenkinsServerparameter is consistent with the switch to Jenkins REST API.This change cleanly aligns with the PR objective to remove the Jenkins client dependency. The existing usage of
jenkinsJobPermissionsServiceshould suffice for request mocking.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionAndResultGitlabJenkinsIntegrationTest.java (1)
49-50: Confirm alljenkinsServerreferences are removed and no calls remain elsewhere.This change cleanly reflects the PR objective to eliminate the Jenkins client by removing
jenkinsServerfrom the mocking setup. Please verify that no other references tojenkinsServerexist throughout the codebase.✅ Verification successful
jenkinsServerreferences are replaced withjenkinsServerUri- no issues foundThe search results show that all instances of
jenkinsServerhave been properly replaced withjenkinsServerUrithroughout the codebase. The references are consistently used in both test and main code for building endpoints and URIs in Jenkins-related services. This change aligns with the PR's objective of cleaning up Jenkins client references while maintaining the necessary URI-based connectivity.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for any remaining references to 'jenkinsServer' throughout the code. rg 'jenkinsServer'Length of output: 10840
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobPermissionServiceTest.java (1)
31-31: Removal ofjenkinsServerparameter is consistent with the new direct REST API approach.The updated call to
enableMockingOfRequestsno longer requires thejenkinsServerparameter, aligning with the goal to eliminate the Jenkins client. This simplification looks good.Run the following script to confirm that no other references or usages of
jenkinsServerremain, ensuring the old Jenkins client is fully removed:✅ Verification successful
The removal of
jenkinsServerparameter is consistent with the REST API approachThe search results confirm that all references to
jenkinsServerin the codebase are now usingjenkinsServerUriinstead, which is consistent with the direct REST API approach. ThejenkinsServerUriis used to construct endpoint URLs for making HTTP requests directly to Jenkins, rather than using the Jenkins client library.This change aligns with the goal of eliminating the Jenkins client dependency and simplifying the integration by using direct REST API calls.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that references to jenkinsServer are removed throughout the codebase. rg -A 5 "jenkinsServer"Length of output: 49079
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTemplateIntegrationTest.java (2)
207-207: Consistent mocking approach
Repeating the same call withoutjenkinsServerin tearDown is consistent with the simplified Jenkins mocking approach. No further changes appear necessary here.
193-193: Removal of jenkinsServer from mocking setup
This change aligns with the transition away from the Jenkins client. Ensure that no other references tojenkinsServerremain in this test setup or related tests.✅ Verification successful
Remaining references to
jenkinsServerare in test infrastructure codeThe references to
jenkinsServerfound in the codebase are all within test infrastructure code, specifically in:
JenkinsRequestMockProvider: A test utility class that mocks Jenkins HTTP requestsAbstractProgrammingIntegrationJenkinsGitlabTest: A base test class for Jenkins/Gitlab integration testsJenkinsAuthorizationInterceptorTest: A test class for Jenkins authorizationThese references to
jenkinsServerUriare used to construct URIs for mocking HTTP requests in tests and don't represent actual Jenkins client usage. This aligns with the transition away from the Jenkins client while maintaining the necessary test infrastructure.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify there are no remaining references to `jenkinsServer` in the test package. rg 'jenkinsServer' src/test/java -A 5Length of output: 24078
src/test/java/de/tum/cit/aet/artemis/programming/ContinuousIntegrationTestService.java (2)
9-9: Consistent use ofURIoverURL
ReplacingURLwithURIoffers enhanced consistency for representing server addresses across the codebase.
36-36: Adoption ofURIforciServerUrl
Switching fromURLtoURIin the service tests aligns with the updated approach throughout the application, ensuring uniform handling of server addresses.src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsAuthorizationInterceptorTest.java (1)
42-42: Confirm consistency with the new mocking approach.Replacing the old parameter (likely
jenkinsServer) withjenkinsJobPermissionsServiceensures that only job permissions logic is mocked. Verify that this change aligns with all other test cases and doesn't inadvertently break or omit necessary Jenkins server interactions.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionIntegrationTest.java (6)
98-98: Good use of simplified mocking approach.
No issues found; removing thejenkinsServerparameter streamlines the method call.
138-138: ConsistentenableMockingOfRequestsusage.
This change is in line with the new Jenkins API approach; looks good.
169-169: Further simplification of Jenkins mocking.
No concerns; matches the updated interface.
213-213: Continued pattern of Jenkins mocking updates.
No functional or performance issues identified.
285-285: Same mocking technique across tests.
The approach is consistent and avoids duplicative parameters.
363-363: Repeated setup for mocking requests.
The single-parameter invocation is clear and consistent with previous lines.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseIntegrationJenkinsGitlabTest.java (1)
32-32: Usage change from jenkinsServer to jenkinsJobPermissionsService looks good.
No functional or syntactical issues found. The updated parameter aligns with the direct Jenkins REST API approach.src/test/java/de/tum/cit/aet/artemis/exercise/service/ParticipationServiceTest.java (1)
101-101: Confirm removal ofjenkinsServerreferences and validate mocking adequacy.The removal of
jenkinsServerfrom theenableMockingOfRequestscall indicates that Jenkins server interactions might no longer need direct mocking. However, please verify that all references tojenkinsServerhave indeed been removed or replaced throughout this test class, ensuring that tests relying on Jenkins server functionality are still fully covered.Below is a shell script to locate any references in the codebase that might still mention
jenkinsServer:✅ Verification successful
Let me search for any references to
jenkinsServerin the test file under review.
Let me check the test file content to understand the context better.
Let me check the base test class to understand the context of
jenkinsServerusage.
The removal of
jenkinsServerparameter is correct and consistent with the codebaseAfter analyzing the codebase, I can confirm that the removal of
jenkinsServerfrom theenableMockingOfRequestscall is correct. TheJenkinsRequestMockProviderclass has been designed to handle Jenkins server interactions internally through its ownjenkinsServerUrifield, and the mock setup doesn't require the server parameter anymore. This is consistent with how the mock provider is used throughout the test classes, including the base test classAbstractSpringIntegrationJenkinsGitlabTestwhere it's used in the same way.The mocking adequacy is maintained as the
JenkinsRequestMockProviderstill handles all the necessary Jenkins server interactions for the tests through its internal configuration.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that jenkinsServer references have been removed or replaced. # Search for references to jenkinsServer in all Java files rg "jenkinsServer" -A 5 --glob "*.java"Length of output: 49095
Script:
#!/bin/bash # Search for jenkinsServer references in the test file rg "jenkinsServer" -A 5 src/test/java/de/tum/cit/aet/artemis/exercise/service/ParticipationServiceTest.javaLength of output: 107
Script:
#!/bin/bash # Get the content of the test file cat src/test/java/de/tum/cit/aet/artemis/exercise/service/ParticipationServiceTest.javaLength of output: 16510
Script:
#!/bin/bash # Get the content of the base test class cat src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.javaLength of output: 31318
src/test/java/de/tum/cit/aet/artemis/exam/ExamUserIntegrationTest.java (1)
110-110: Simplify Jenkins mocking approach.Removing the
jenkinsServerparameter in favor of a singlejenkinsJobPermissionsServiceargument clarifies the test setup. Ensure that any references tojenkinsServerhave been fully removed and that no other tests or production code still rely on the old parameter.Run the following script to confirm any lingering references to
jenkinsServer:src/test/java/de/tum/cit/aet/artemis/exercise/participation/ParticipationIntegrationTest.java (2)
1360-1360: Consistent usage of the new Jenkins mockingReusing
jenkinsJobPermissionsServicehere aligns well with the refactored approach to Jenkins mocking. This maintains consistency with the approach at line 408.
408-408: Simplify the mocking approach and remove legacy referencesThe new parameter
jenkinsJobPermissionsServiceis a cleaner alternative to the oldjenkinsServer. Verify that any remaining references tojenkinsServerare also removed to avoid confusion and ensure consistency throughout the codebase.Here is a verification script to detect any remaining references:
✅ Verification successful
Let me analyze the references to
jenkinsServerin the codebase to verify if there are any legacy references that need to be removed.
No legacy references to
jenkinsServerfoundThe search results show that all occurrences of "jenkins" in the codebase are using the new
jenkinsServerUripattern. There are no standalone references to the oldjenkinsServervariable, indicating that the codebase is already consistent with the new approach usingjenkinsJobPermissionsService.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Searches for any references to 'jenkinsServer' in the repository rg 'jenkinsServer'Length of output: 10840
Script:
#!/bin/bash # Search for 'jenkinsServer' as a standalone variable/parameter (not part of jenkinsServerUri) rg '\bjenkinsServer\b' -g '!*.md'Length of output: 35
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobServiceTest.java (6)
26-26: New Import for JenkinsJobService
This import accurately reflects the updated references in the test class.
41-41: Update Mocking References
Ensuring thatenableMockingOfRequestsis invoked withjenkinsJobPermissionsServiceinstead of the previous parameter streamlines the test setup. Verify that any dependencies or references to the old parameter are removed or updated as well.
63-64: Instantiating JobWithDetails
Using theJenkinsJobService.JobWithDetailsobject directly is a clean approach that clarifies the job name and flags. This aligns well with the shift away from older mocking patterns.
74-75: Mocking the Non-Existing Job
The code correctly ensures that the job is mocked asnullwhen it does not exist, verifying that a creation path is then tested. This improves test clarity and reliability.
78-79: Verifying Job Creation
The addition to verify job creation within the same test scenario is consistent. Including finalverifyMocks()calls ensures no unintended interactions go unnoticed.
85-85: Exception Handling Coverage
Mocking job creation in the folder and verifying that an invalid XML leads to aJenkinsExceptionis a robust test scenario. This helps confirm reliable error handling in the broader Jenkins integration.src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java (2)
102-102: Consistent removal of obsolete references.This change properly omits resetting the removed
jenkinsServermock. Please ensure no additional references tojenkinsServerremain in the tests.
323-323: Verify the usage of identical source and target project keys.Here,
mockCopyBuildPlanFromTemplate(projectKey, projectKey, participation.getBuildPlanId())passes the same value for both source and target project keys. This might override the same resource. Please confirm that this is the intended behavior or adjust accordingly.✅ Verification successful
Let me analyze the usage patterns of
mockCopyBuildPlanFromTemplateto understand if using identical source and target project keys is the intended behavior.
Let me try a different approach to understand the context better.
Let me check one more thing to understand the pattern in the parent class.
Using identical source and target project keys is the correct implementation
The usage of identical project keys for source and target in
mockCopyBuildPlanFromTemplate(projectKey, projectKey, participation.getBuildPlanId())is intentional and correct. Here's why:
- This is a test mock implementation of the
MockDelegateinterface'smockCopyBuildPlanmethod- The context shows this is specifically for student participation builds, where the build plan is created within the same project
- Other implementations in the codebase show that when copying between different projects (like exercises), different source and target keys are used
- The pattern is consistent across the test implementations, where student participation builds use the same project key
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for calls to mockCopyBuildPlanFromTemplate to verify if the source and target should differ. rg -A 2 "mockCopyBuildPlanFromTemplate"Length of output: 5456
Script:
#!/bin/bash # Let's look at the implementation of mockCopyBuildPlanFromTemplate and related methods ast-grep --pattern 'public void mockCopyBuildPlanFromTemplate($$$) { $$$ }'Length of output: 201
Script:
#!/bin/bash # Let's examine the test class to understand the context where this mock is used rg -B 5 -A 5 "mockCopyBuildPlanFromTemplate\(projectKey, projectKey" src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.javaLength of output: 780
Script:
#!/bin/bash # Let's check the interface or parent class to understand the contract rg -B 2 -A 2 "mockCopyBuildPlan.*Participation" --type javaLength of output: 6628
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsServiceTest.java (11)
44-44: Consistent mocking approach.
This line properly updates the parameter list to align with the new direct REST interaction with Jenkins, removing any leftover Jenkins server references.
183-186: Duplicate calls to mockCopyBuildPlanFromTemplate.
This logic mirrors lines 164-167. A unified helper would reduce code duplication across tests.
210-211: Confirm the use of null.
Please verify that passingnullas an argument formockGetJobis intended and does not lead to issues in test scenarios for job retrieval.
215-215: Centralized verification is good practice.
The singleverifyMocks()call ensures correctness across the entire test flow. This is a clear approach to verifying Jenkins mocking.
230-230: Remove unnecessary exception throws.
DroppingURISyntaxExceptionmakes sense if no URIs are being assembled in the test logic. Confirm that no usage paths require it.
296-296: Empty string for template name.
Using""might confuse readers if they expect a name or ID. Double-check that it is indeed valid and handled properly by your service logic.
314-315: Descriptive shortName assignment.
Setting the shortName to"source"and regenerating the project key clarifies this test scenario. This is a clear, well-labeled setup.
325-325: Consistent naming for target exercise.
Setting"target"helps distinguish between the craft source/target plan scenarios.
330-330: Constructing the target plan name.
DefiningtargetPlanNamethis way ensures consistent naming across the Jenkins tests and reduces guesswork.
331-331: Explicitly specifying the plan name.
By passingtargetPlanName, the test scenario is clear for verifying that the template plan is properly copied to the target.
333-333: Comprehensive copyBuildPlan call.
Providing all necessary arguments, including the template name andtruefor forcibly copying, ensures consistent coverage of multiple parameters in this test.src/test/java/de/tum/cit/aet/artemis/modeling/apollon/ApollonConversionServiceTest.java (1)
40-40: Encapsulation improved by reducing variable visibility.
Switching the field to private is consistent with general best practices for test classes, ensuring clear ownership and limiting exposure.build.gradle (21)
22-22: New Gradle lint plugin addition.
Including the "nebula.lint" plugin can help catch Gradle misconfigurations early on. Ensure the lint rules align with your project’s standards.
127-127: Empty line insertion.
No action needed for this blank line.
129-129: Empty line insertion.
No action needed.
138-138: Empty line insertion.
No action needed.
142-142: Empty line insertion.
No action needed.
145-145: Empty line insertion.
No action needed.
255-258: Hazelcast integration introduced.
Hazelcast can significantly improve synchronization in multi-node setups. Confirm that concurrency and reliability needs are thoroughly tested.
298-298: Spring Retry for asynchronous operations.
Spring Retry is powerful. Confirm you have robust tests around retry logic to avoid silent loops or unexpected behavior.
336-336: IPAddress library included.
Helpful for parsing and manipulations of IP addresses. Confirm no overlap or duplication with built-in Java or third-party libraries.
339-339: Additional libraries for PDF, CSV, CommonMark, File Upload, and ZIP.
These are typically standard in multi-functional systems. Confirm all introduced features are tested if they’re newly integrated here.
346-346: Blank line added.
No further action needed.
499-499: Blank line added.
No further action needed.
259-259: Hibernate 2nd level cache with Hazelcast.
Great for caching across multiple nodes. Double-check that all spring configurations (e.g., inapplication*.yml) are adjusted accordingly.✅ Verification successful
Hazelcast cache configuration is properly set up in application YML files
The verification shows that Hazelcast is correctly configured in both main and test application.yml files with the necessary settings:
- Hibernate cache region factory is properly set to
HazelcastLocalCacheRegionFactory- Instance name is configured as "Artemis"
- Lite member mode is enabled
- Port configuration (5701) is present
- Docker configuration includes the required Hazelcast port exposure
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Checking for existing Hazelcast cache configuration references in application YMLs. fd --type f yml | xargs grep -i "hazelcast"Length of output: 1270
136-137: Exclude the Xalan serializer.
Similar caution applies; confirm no pipeline logic depends on these classes.✅ Verification successful
Xalan serializer exclusion is safe to proceed
The grep results show that the only reference to the Xalan serializer is in the exclusion line itself within
build.gradle. All other serializer-related code in the codebase refers to different serialization mechanisms:
- JSON serialization (ActionDeserializer, JavaClassDiffSerializer)
- Hazelcast serialization (HazelcastPathSerializer)
- DOM/XML serialization from NPM packages
- Custom serialization utilities (SerializerUtil)
None of these components depend on or use the Xalan serializer library. The comment in the code also explicitly states it's "required by JPlag, but not used in this project", which is consistent with our findings.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search references to Xalan serializer. grep -Ri 'serializer' .Length of output: 8742
143-144: Excluding javax cache and transaction APIs.
Confirm these APIs are not essential in application transaction flows or caching frameworks.✅ Verification successful
Excluding javax cache and transaction APIs is safe
The codebase uses Spring's caching abstraction (
@Cacheable,@Cache) and transaction management (@Transactional) annotations, which are independent of the excluded JCache (JSR-107) and JTA APIs. The application:
- Uses Hibernate's second-level cache with
CacheConcurrencyStrategy.NONSTRICT_READ_WRITEstrategy- Manages transactions through Spring's
@Transactionalannotation- Implements caching through Spring Cache annotations (
@Cacheable,@CacheEvict, etc.)These functionalities work without the excluded dependencies as they rely on Spring's implementations rather than the standard Java APIs.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Confirm that javax.cache or javax.transaction are not referenced. grep -Ri 'javax.cache\|javax.transaction' .Length of output: 201
Script:
#!/bin/bash # Search for cache-related imports and usage rg -l "import.*cache" # Search for transaction-related imports and usage rg -l "import.*transaction" # Search for @Transactional annotations rg "@Transactional" # Search for Cache annotations or implementations rg "@Cache|@Cacheable"Length of output: 53209
139-141: Excluding cache, micrometer, and logstash dependencies.
Ensure no code paths rely on Spring Boot caching, micrometer metrics, or logstash for advanced logging.✅ Verification successful
Dependencies are safely excluded as no active usage found
The codebase scan shows that the excluded dependencies (spring-boot-starter-cache, micrometer-registry-prometheus, logstash-logback-encoder) are not actively used in the application code:
Spring Cache: While there are some Hibernate caching annotations and ts-cacheable (client-side) usage, there are no Spring
@Cacheableor other Spring Cache annotations being used for application caching.Micrometer/Prometheus: The references found are only in configuration files and metrics setup code, but the actual prometheus registry is excluded, so the metrics will use a different registry.
Logstash: No logstash configuration or usage found in the codebase. The logging appears to use standard logback without the logstash encoder.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search references to spring-boot-starter-cache, micrometer-registry-prometheus, logstash-logback-encoder grep -Ri 'spring-boot-starter-cache\|micrometer-registry-prometheus\|logstash-logback-encoder' .Length of output: 381
Script:
#!/bin/bash # Search for Spring Cache annotations and imports rg -i "@Cacheable|@CacheEvict|@CachePut|@EnableCaching|@Caching|import.*cache" -g "!build.gradle" # Search for Micrometer/Prometheus related code rg -i "micrometer|prometheus|@Timed|MeterRegistry|Counter\.|Gauge\.|Timer\." -g "!build.gradle" # Search for Logstash/Logback configuration and usage fd -e xml -e properties -e yaml -e yml | xargs rg -i "logstash|logback"Length of output: 81826
130-131: Exclude XStream from the classpath.
XStream is excluded. Confirm that no XML serialization logic depends on it.✅ Verification successful
Let me search for any XML serialization related code to ensure there are no dependencies on XStream.
Let me search for any XML serialization/deserialization code that might depend on XStream.
XStream exclusion is safe - no XML serialization dependencies found.
The codebase uses Jackson for JSON serialization and standard Java XML libraries (javax.xml) for Jenkins configuration. No direct dependencies on XStream were found in the code. The exclusion is safe as mentioned in the comment "required by eureka client, but not used in this project".🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for any usage of XStream in the codebase. grep -Ri 'XStream' .Length of output: 100
Script:
#!/bin/bash # Search for XML serialization related code patterns rg -i "xml|serialize" --type java -g "!build*" -g "!gradle*"Length of output: 69969
Script:
#!/bin/bash # Search for XStream related code patterns rg -i "xstream|serializ" --type java -g "!build*" -g "!gradle*" -A 5 -B 5Length of output: 74008
146-148: Excluding JGraphT and apfloat.
Both are potentially used in advanced graph or math computations. Verify no code uses these libraries.✅ Verification successful
No usage of JGraphT or Apfloat libraries found in the codebase
The search results confirm that the only references to JGraphT and Apfloat are in the build.gradle file where they are being excluded. No actual usage of these libraries was found in the source code. The exclusions appear to be safe to keep.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for references to JGraphT or Apfloat. grep -Ri 'jgrapht\|apfloat' .Length of output: 170
Script:
#!/bin/bash # Search for imports or usage of JGraphT classes rg -i "import.*jgrapht|jgrapht\." -g "!build.gradle" # Search for imports or usage of Apfloat classes rg -i "import.*apfloat|apfloat\." -g "!build.gradle" # Check if these are transitive dependencies by examining dependency tree ./gradlew dependencies | grep -i "jgrapht\|apfloat"Length of output: 348
Script:
#!/bin/bash # Let's try a different approach to search for any potential usage # Search for class names or method calls that might be from these libraries rg -i "Graph[A-Z][a-zA-Z]+|DirectedGraph|UndirectedGraph|DefaultEdge|GraphPath" -g "!build.gradle" -g "!*.md" -g "!*.txt" # Search for mathematical computation related terms from Apfloat rg -i "Apfloat|Apcomplex|Aprational|ApfloatMath" -g "!build.gradle" -g "!*.md" -g "!*.txt" # Also check for any configuration files that might reference these fd -e xml -e properties -e gradle | xargs grep -i "jgrapht\|apfloat" 2>/dev/null || trueLength of output: 120383
132-133: Exclude Xerces library.
Verify no portion of the code relies on Xerces for XML parsing.✅ Verification successful
Let me search for any XML parsing related code to ensure there's no indirect dependency on Xerces.
Let me search for any actual XML parsing code to ensure there's no dependency on Xerces.
Let me check if the codebase uses any alternative XML parsers.
Xerces exclusion is safe to apply.
The codebase uses standard Java XML parsing libraries (javax.xml) and does not rely on Xerces. The XML parsing is done through DocumentBuilderFactory and related standard Java APIs, which can use any compliant XML parser implementation. The Xerces exclusion in build.gradle is explicitly marked as "required by JPlag, but not used in this project" and the code analysis confirms this.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for references to Xerces in the codebase. grep -Ri 'xerces' .Length of output: 84
Script:
#!/bin/bash # Search for XML-related imports and usage rg -i "xml|documentbuilder|saxparser|xpath" -g "!*.{xml,gradle}"Length of output: 89898
Script:
#!/bin/bash # Search for XML parsing related imports and code rg -i "documentbuilder|saxparser|xmlparser|xerces" -g "!*.{xml,gradle}"Length of output: 5324
Script:
#!/bin/bash # Search for other XML parsing related imports rg -i "javax.xml|org.xml|xml.parsers" -g "!*.{xml,gradle}"Length of output: 4621
128-128: Confirm absence of jasypt usage.
Jasypt is being excluded. If the project previously relied on encryption or decryption features from jasypt, verify that it is no longer necessary.✅ Verification successful
Let me search for any encryption-related code or configuration that might have used jasypt previously.
Let me search for any encryption-related dependencies that might have replaced jasypt.
Let me try a different approach to check for encryption-related code and dependencies.
Jasypt exclusion is safe - Spring Security Crypto is used instead
The codebase has explicitly excluded jasypt and is using Spring Security's crypto module (
spring-security-crypto) for encryption needs. The only encryption usage found is for e2e encrypted notifications via the Hermes service. This is a safe replacement as Spring Security's crypto module is a more modern and maintained solution for encryption needs.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for references to jasypt in the codebase. grep -Ri 'jasypt' .Length of output: 84
Script:
#!/bin/bash # Search for common jasypt usage patterns and encryption-related code rg -i "encrypt|decrypt|@EnableEncrypt|ENC\(" # Look for any configuration files that might have encrypted properties fd -e properties -e yml -e yaml -x cat {}Length of output: 69409
Script:
#!/bin/bash # Search for encryption-related dependencies in build files rg -i "implementation.*encrypt|compile.*encrypt|api.*encrypt" # Look for any encryption-related code ast-grep --pattern 'class $_ { $$$ encrypt($$$) { $$$ } $$$ }'Length of output: 264
Script:
#!/bin/bash # Search for any encryption-related classes or methods rg -i "class.*[Ee]ncrypt|interface.*[Ee]ncrypt|@[Ee]ncrypt|[Ee]ncrypt.*Service|[Ee]ncrypt.*Provider" # Check for any jasypt-related configuration or properties rg -i "jasypt\.encryptor|ENC\(|PBEWith|jasypt\.password" # Look for other encryption-related dependencies in build.gradle rg -i "org\.jasypt|encryption|crypto" build.gradleLength of output: 512
134-135: Exclude Xalan library.
Just ensure that no Xalan-based transformations are required.✅ Verification successful
Let me search for any XML transformations or XSLT usage in the codebase to ensure there are no dependencies on Xalan.
Let me check for any XSLT or XML transformation usage in the Java source files.
Let me try a different approach to search for XML transformation usage.
Let me check the actual XML transformation code in these files to understand the usage.
Excluding Xalan is safe - no Xalan-specific transformations used.
The codebase uses standard JAXP (Java API for XML Processing) transformations through
TransformerFactoryandTransformerclasses, which are part of thejavax.xml.transformpackage. The implementation uses the default transformer factory instance without requiring any specific implementation like Xalan. The XML transformations are only used for basic DOM to String conversion in Jenkins-related utilities.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search references to Xalan. grep -Ri 'xalan' .Length of output: 141
Script:
#!/bin/bash # Search for XML transformation related imports and usage rg -i "transform|xslt|javax\.xml"Length of output: 67447
Script:
#!/bin/bash # Search for XML transformation related classes and methods ast-grep --pattern 'class $_ { $$$ transform($$$) { $$$ } $$$ }'Length of output: 202
Script:
#!/bin/bash # Search for XML transformation related classes and usage rg -l "TransformerFactory|Transformer|XSLT|XSLTTransformer|XmlTransformer"Length of output: 555
Script:
#!/bin/bash # Check the XML transformation implementation rg -A 5 "TransformerFactory|Transformer|XSLT|XSLTTransformer|XmlTransformer" src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.javaLength of output: 950
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsService.java (9)
3-5: Good use of the new profile constant and URI import.
This change improves maintainability by referencing a central constant and transitioning to usingURI.
42-42: Profile annotation alignment.
Switching to@Profile(PROFILE_JENKINS)is consistent with using constants and prevents literal typos.
51-51: Replacing URL with URI.
UsingURIfor the server address simplifies path manipulation and is more robust.
67-69: Constructor-based DI is well-structured.
Constructor injection aligns with best practices; fields are clearly assigned and dependencies are explicit.
149-149: Deletion of folder job via job service.
Removing direct interactions with the Jenkins client is consistent with the PR objective of using REST directly.
154-154: Deletion of build plan via job service.
This is another step in removing the Jenkins client dependency.
201-202: Check-if-project-exists logic is clear.
If the Jenkins folder job is missing, we return null; otherwise, we indicate the project already exists. The messaging is straightforward and correct.Also applies to: 207-207
234-234: Health method uses short-timeout REST checks.
This implementation is correct but ensure you handle 4xx/5xx gracefully. Currently, all exceptions lead to the same error.Also applies to: 236-236, 238-238
249-251: Creating folder with error wrapping.
CatchingExceptionand rethrowing a more specificJenkinsExceptionis appropriate for consistent error handling in this codebase.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java (22)
3-4: Consistent profile constant usage.
Using@Profile(PROFILE_JENKINS)ensures consistency across Jenkins-related classes.
6-6: URI import for Jenkins server URLs.
Transitioning fromURLtoURIaligns with the rest of the refactoring.
12-12: Qualifier import alignment.
No issues found; constructor injection remains clear.
15-17: HTTP entity and headers usage.
The addition of these imports for handling request bodies is consistent with REST usage.
19-21: Exception imports for REST calls.
Introducing these exceptions allows finer-grained error handling compared to the old Jenkins client approach.
24-25: Jackson annotations for new record classes.
@JsonIgnoreProperties(ignoreUnknown = true)and@JsonInclude(JsonInclude.Include.NON_EMPTY)keep JSON parsing robust.
28-28: Endpoints import.
Centralizing endpoint definitions inJenkinsEndpointsimproves maintainability.
32-32: Profile annotation switching.
Unified usage of@Profile(PROFILE_JENKINS)reduces the risk of misconfigurations.
37-37: RestTemplate usage.
Dependency injection ofRestTemplateis consistent and supports the new REST-based approach.
39-40: Switched to URI for Jenkins server address.
This matches the widespread shift in the codebase for standardized URL handling.
42-43: Constructor injection with Jenkins-specific dependencies.
No issues; this adheres to established best practices.
53-53:getJobmethod signature changes.
Renaming fromgetJobInFoldertogetJobimproves clarity and consolidates logic.
59-63: Error handling with success/failure paths.
CatchingNotFoundexplicitly for a missing job is a clear approach, though watch for potential SSRF with externally constructed URIs if user inputs are not validated.
67-67: General catch block for REST errors.
Throws aJenkinsExceptionto standardize error reporting. Looks good.
73-81: Record classes for job details & folder jobs.
Using records for DTO-like objects is a neat, immutable approach.
91-97:getFolderJobmethod with safe fallback.
Returningnullif the folder does not exist clarifies the API usage.
110-110: Method signature forgetJobConfig.
Loading job XML config from Jenkins is straightforward.
114-114: Exception thrown when folder missing.
Informative error message helps debug misconfigurations quickly.
117-119: Retrieving and parsing job config.
Replacing references to branches is helpful but ensure consistent branch naming in the codebase.
126-130: HandlingNotFoundfor job config.
Logging and rethrowing as aJenkinsExceptionkeeps error handling uniform.
153-169: NewcreateFoldermethod and related usage.
This block sets up Folder creation logic aligned with the new REST approach. The use of query parameters ensures clarity for the Jenkins server calls.
211-215: Folder existence check logic forcheckIfProjectExists.
Replaces the old Jenkins API calls with a simpler REST approach. The fallback for error scenarios is consistent.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanService.java (12)
4-4: Constant usage for Jenkins profile.
This matches the other classes, maintaining consistency in how profiles are named.
60-60: Profile annotation with new constant.
Using@Profile(PROFILE_JENKINS)is coherent across the codebase.
66-66:jenkinsServerUrias aURI.
Consistent with the replaced references elsewhere.
99-99: Constructor changes removing JenkinsServer.
Dependency on direct Jenkins client is removed, fulfilling the PR’s main objective.
215-215: Replacing script parameters in job config.
This step is crucial to ensure the correct repository URIs after the switch to REST.
224-224: Updating job via job service.
Refactoring to rely onjenkinsJobServicekeeps the domain logic consistent.
290-290: Retrieving job config before creating new job.
CallingjenkinsJobService.getJobConfigfrom the old plan ensures we copy accurate config.
311-312: Trigger build step with REST call.
Posting to the Jenkins endpoint to start builds is straightforward. If authentication fails or the job is missing, the exception is caught.
329-335: Queued vs. inactive status detection.
Relies on theinQueueproperty to determine if a build is queued. This approach is simpler than the old Jenkins client.
340-342: Retrieving last build status.
Mapping thebuildingfield toBuildStatus.BUILDINGis direct but ensure edge cases (e.g., partially queued or canceled builds) are handled.
350-353:JenkinsBuildStatusDTOrecord.
Immutability and ignoring unknown properties reduce potential JSON parse errors.
380-380: Folder existence check for build plan.
A null check fromgetJobis enough to confirm if the plan exists, simplifying older logic.src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.java (45)
3-5: Consistent usage of import and build plan type references.
No functional issues; consolidating constants in test code is beneficial.
14-15: Mock REST response creators.
AdoptingwithBadRequestandwithResourceNotFoundclarifies test scenarios for negative paths.
20-20: Switch toURIfor jenkinsServerUri.
Keeps test logic consistent with the production code’sURIusage.
45-46: Use of JenkinsJobService references in test setup.
Directly referencingJenkinsJobServicerecords ensures test coverage of newly introduced DTOs.
49-49: Dependency injection import.
No issues; consistent with the rest of the PR’s transition to direct Jenkins calls through REST.
53-53: Profile annotation updated.
Aligns test code with production code’s usage ofPROFILE_JENKINS.
57-57:jenkinsServerUriis now a URI.
Matching production code changes ensures test correctness.
89-89: Simplified method signature for enabling request mocking.
Dropping the JenkinsServer parameter clarifies usage of the new test approach.
115-123:buildJobNamehelper method.
This short utility method unifies job naming logic in tests, reducing duplication.
126-138: Mocking new folder creation endpoints.
The code expects either success or a bad request, reflecting typical Jenkins responses.
143-145: Combining job creation, plan permissions, and trigger build.
This chain of mocks ensures the new REST approach is thoroughly tested for a typical use case.
151-153:mockCreateCustomBuildPlanlogic.
Correctly aligns with Aeolus custom build plan creation calls in test contexts.
162-171: Job existence checks vs. creation flow.
Use of folder checks andcreateJobcalls accurately mirrors real Jenkins job creation paths.
180-190: Mocking plan permission assignment.
Ensures we fully test the transitional step from job creation to updating job config for permissions.
196-200: Loading test resource for job config.
Retrieving a realistic XML config file helps validate the actual config interactions.
204-207: Mock coverage for folder config.
Ensures folder-level config retrieval is included in negative/positive path testing.
211-220:mockCheckIfProjectExists: negative vs. positive.
Differentiates the success response and a bad request to simulate real Jenkins conditions.
225-226: Handling null jobs in “project exists” check.
Properly returns if the folder job is absent.
228-233: Mock scenario: a job URL is empty.
Ensures the code can handle partial data from Jenkins gracefully.
235-252: Copy build plan from templates or solution.
Modular approach with folder existence checks helps reuse logic across multiple test flows.
254-262: Saving job XML in different folder states.
Tests creation logic in either existing or new folder scenarios.
265-265: Mock configuring build plan.
Ensures the newly introduced update steps flow is tested for real usage patterns.
276-285: Repository update mocking with repeated triggers.
Simulates real Jenkins usage by calling the update endpoint multiple times, covering concurrency scenarios.
291-295: Verifying partial success or failures.
Uses flexible HTTP status checks for updatePlanRepository calls.
301-304: GET vs. POST for plan config.
One method retrieves existing XML; the other updates. This tests both paths thoroughly.
Line range hint
307-314: Enabling plans with success/failure states.
Handling 404 or other errors tests error-handling logic in the production code thoroughly.
320-321: Copying build plans ensures reuse of mock logic.
Leverages the template copying approach, ensuring coverage for standard reusability.
324-333: Mocking “getJob” with success or failure.
This test covers both the valid JSON scenario and a forced error.
337-339: Folder job retrieval
Ensures the folder job can be returned or is absent. Critical for high-level test flows.
341-344:mockGetFolderJobwith real JSON representation.
Tests the basic Jenkins folder metadata retrieval path.
347-355: User update and group removal
Combines user existence checks with removal from groups to test corner cases.
358-364: Updating user login
Ensures correct coverage of rename flows, including old/new login checks.
376-379: Deleting users if they exist
Combines “get user” calls with the final remove user call. Checks error paths as well.
Line range hint
386-402: Flexible user existence states
The code can handle “user missing,” “access forbidden,” or “200-level” responses.
428-435: Creating user in Jenkins
Consistent usage ofCREATE_USERendpoint with fallback for group addition.
438-446: Adding users to groups
Resolves folder config for each exercise to reflect new group membership logic.
497-502: Handling success/failure when adding permissions
Test ensures the system logs errors and does not silently ignore them.
507-513: Mock job deletion
Simulates the new deleteJob endpoint usage, verifying success or bad request scenarios.
518-520: NotFound scenario for job deletion
Ensures code gracefully handles a non-existent plan.
524-526: Additional job deletion failure
Covers an unexpected bad request scenario from Jenkins.
530-535: Project folder deletion
Mirrors the job deletion logic, ensuring consistent coverage.
540-554: Mocking queued vs. building statuses
Different states for job existence and build progress are tested thoroughly.
560-562: Health checks
Simulating either correct or error states ensures shortTimeout usage is validated.
572-572: Check build plan existence
UsesmockGetJobto confirm if the plan is present, matching the production logic.
577-585: Trigger build success/failure
Mimics real behavior of Jenkins during triggered builds, ensuring thorough negative path testing.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInternalUrlService.java (2)
3-4: Replaced @Profile("jenkins") with constant.
Enhances maintainability by centralizing the profile string.
14-14: Class-level profile annotation.
No functional changes beyond referencingPROFILE_JENKINS. This is consistent with the rest of the PR.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanLinkInfoContributor.java (4)
3-4: Adopted constant-based profile.Using
PROFILE_JENKINSrather than a hardcoded string helps to centralize and maintain profile values more reliably.
5-5: Switch toURIimport is appropriate.Replacing
URLwithURItypically provides clearer semantics for handling addresses, improving consistency across the codebase.
16-16: Use of@Profile(PROFILE_JENKINS)is consistent.Refactoring to the constant-based approach aligns with the standardization of profile usage across the application.
20-20: Refactored field type fromURLtoURI.This change is beneficial for clarity, but verify edge cases (e.g., invalid or partial URIs).
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInfoContributor.java (3)
3-5: Consistent constant import andURIusage.Using
PROFILE_JENKINSandURIfosters a uniform approach to profile handling and address references.
16-16: Harmonized profile declaration.Switching to
@Profile(PROFILE_JENKINS)ensures consistency with other Jenkins-related classes.
20-20: Field type changed toURI.Verify that all consumers and environment variables match this new type to prevent runtime issues.
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsTriggerService.java (2)
3-4: Static import ofPROFILE_JENKINS.This change eliminates magic strings and improves maintainability.
12-12: Profile annotation standardized.Refactoring to
@Profile(PROFILE_JENKINS)aligns this service class with the unified profile approach across the codebase.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsEndpoints.java (5)
3-3: New import forURI.Facilitates endpoint-building with a more precise address type. Confirm all references are updated accordingly.
13-26: Added and updated build-related endpoints.Bundling these as dedicated enum constants clarifies usage and avoids hard-coded strings scattered across the code. Ensure end-to-end tests confirm these enumerated paths function correctly.
27-29: Introduced a health check endpoint.Provides an explicit route (
login) for verifying Jenkins status. Validate iflogintruly correlates to a meaningful health check response.
30-34: New user management endpoints.Endpoints like
GET_USER/DELETE_USER/CREATE_USERunify user-related operations. Confirm security and permission checks are enforced properly on the Jenkins side.
42-43: RefinedbuildEndpointmethod signature.Shifting from
String...to(URI baseUri, Object... args)improves clarity and type safety. Ensure all callers pass valid URIs and arguments to avoid URL–path mismatch.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsAuthorizationInterceptor.java (5)
3-4: Use of a central profile constant is a good improvement.Replacing the hardcoded profile string with a constant improves maintainability and reduces the risk of typos.
6-6: Switching from java.net.URL to java.net.URI is appropriate.Using URI clarifies semantic intent, especially when manipulating different parts of the resource identifier.
27-27: Annotation consistencyUsing
@Profile(PROFILE_JENKINS)consistently across classes is beneficial for maintainability.
40-40: Refactoring to a URI fieldRenaming and changing the field type to
URIaligns with the broader codebase shift away fromURL.
67-67: Consider edge cases and exception handlingCheck if
jenkinsServerUriis guaranteed non-null. If not, consider adding validation or fallback logic to prevent NullPointerExceptions when building the crumb issuer path.src/test/java/de/tum/cit/aet/artemis/programming/RepositoryProgrammingExerciseParticipationJenkinsIntegrationTest.java (2)
21-21: New import references updated class usageImporting
JenkinsJobServicedirectly reflects the refactoring away from the legacy Jenkins client.
59-62: Verify test coverage for new instantiation approachPreviously, mocks helped isolate unit tests from external logic. Direct object instantiation can introduce side effects or integration aspects if not carefully handled. Confirm that external interactions are sufficiently mocked to prevent flaky tests.
src/main/java/de/tum/cit/aet/artemis/programming/service/InternalUrlService.java (1)
107-107: Using fromUriString allows broader URI formatsSwitching from
fromHttpUrltofromUriStringcan handle more general URIs, which is beneficial for internal routing or non-HTTP schemes.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java (1)
3-3: Profile constant usage ensures uniform configurationReplacing
"jenkins"withPROFILE_JENKINSis consistent with the rest of the codebase. This central approach reduces duplication and potential typos.Also applies to: 36-36
src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.java (6)
3-3: Import usage is consistent.
Using a specific import forjava.net.URIinstead of wildcard imports follows [java:avoid_star_imports] and aligns with best practices.
17-17: Javadoc improvement noted.
The updated documentation for path segment replacement clarifies usage for potential callers.
25-26: Consider input validation forbaseUrl.
IfbaseUrlis malformed or null,UriComponentsBuilder.fromUriString(baseUrl)might throw an exception. You may want to consider validating the input, depending on your usage scenarios.
29-45: Overloaded method is clear and consistent.
Providing an overload forURIparallels the existingStringversion and improves flexibility for callers who already useURIobjects.
46-57: Segment parsing logic looks solid.
Method neatly handles variable replacements and ensures arguments match placeholders. This is consistent with single responsibility and keeps the code DRY.
78-78: Efficient conversion to array.
Using the method reference for converting the ArrayList into a String array is a concise and efficient approach.src/test/java/de/tum/cit/aet/artemis/core/connector/AeolusRequestMockProvider.java (4)
7-7: ImportingwithSuccess()for concise success responses.
Switching towithSuccess()consistently simplifies the setup for successful mock responses.
76-76: Streamlined success response usage.
UtilizingwithSuccess()plus JSON response body and content type is consistent with the rest of the mock provider’s patterns.
114-114: Mocked success response for preview generation.
Again, adoptingwithSuccess()is a neat improvement in clarity over manually settingHttpStatus.OK.
118-118: Bearer token check is preserved.
Ensuring the Authorization header is validated before responding with success maintains security testing coverage.src/test/java/de/tum/cit/aet/artemis/core/service/TelemetryServiceTest.java (4)
9-9: Consistent use ofwithSuccess().
Importing this creator in test harmonizes with the rest of the mock responses.
64-64: Verifying inclusion of sensitive data.
Your test assertion ensures personal data is present when needed, and usingwithSuccess()neatly finalizes the response setup.
76-76: Verifying absence of sensitive data.
This test complements the previous one by ensuring personal data is excluded, andwithSuccess()remains consistent.
88-88: Telemetry disabled case is accurately tested.
Expecting no request is made is a robust approach.withSuccess()keeps the response handling uniform if a request did occur.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsResultService.java (2)
3-3: Constant-based profile improves maintainability.
Relying onPROFILE_JENKINSfromConstantsavoids duplication and the risk of typos.
30-30: Profile annotation usage is consistent.
Switching to@Profile(PROFILE_JENKINS)aligns with the broader refactor throughout the codebase.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanCreator.java (2)
3-4: Centralizing the Jenkins profile annotation.Switching from a hardcoded string to the
PROFILE_JENKINSconstant improves maintainability by reducing the risk of typos and allowing for a single source of truth for this profile definition.
31-31: Profile annotation usage is consistent and clear.Using
@Profile(PROFILE_JENKINS)ensures alignment with the rest of the codebase and avoids hardcoded literals. This improves consistency and eases refactoring in the future.src/test/java/de/tum/cit/aet/artemis/programming/AbstractProgrammingIntegrationJenkinsGitlabTest.java (2)
3-3: New import for URI class.This import is justified by the switch from
URLtoURI, which can provide better parsing and manipulation features for Jenkins server addresses.
69-69: Switching from URL to URI.Changing
jenkinsServerUrltojenkinsServerUrihelps standardize the usage of URI-based operations. Verify that all references and method calls reflect this new type appropriately.src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.java (6)
7-7: Import of PROFILE_JENKINS is consistent with new constants usage.Referencing the constant allows for easier updates of profile definitions across the codebase.
52-52: Jenkins RestTemplate profile.Leveraging
@Profile(PROFILE_JENKINS)for the Jenkins RestTemplate ensures a tailored configuration only loads when needed, reducing overhead.
96-96: Short Timeout RestTemplate for Jenkins.Providing a short timeout variant helps handle faster failover scenarios. Ensure tests cover how this configuration behaves under slow network conditions.
176-176: Short timeout request factory usage.This line properly obtains a client request factory with shorter timeouts. Could be beneficial for health checks or limited-latency calls.
180-185: Encapsulating request factory creation in a helper method.Using a dedicated method to build the factory refines code readability and avoids duplication. Good practice for maintainability and reusability.
187-188: Very short timeout variant.This further specialized method for extremely short timeouts is well-isolated. Consider verifying that these timeouts are not too strict for certain production scenarios.
src/main/java/de/tum/cit/aet/artemis/programming/service/gitlab/GitLabPersonalAccessTokenManagementService.java (2)
151-151: Constructing the URI using fromUriString.Using
fromUriStringis more flexible and aligns with a broader shift away fromfromHttpUrl, ensuring consistent URI handling. Confirm that all references are updated accordingly.
164-164: Consistent URI building approach for fetching tokens.Aligning token fetch logic with
fromUriStringunifies URI handling. This can simplify debugging and reduce potential malformed URL issues.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobPermissionsService.java (4)
3-4: Great use of profile constant instead of a hard-coded string.
This approach improves maintainability and consistency across the codebase.
11-11: Explicit import ofDocumentpromotes code clarity.
Switching from inferred types to declared ones can make the code easier to read, facilitating better maintenance.
14-14: Replacing@Profile("jenkins")with@Profile(PROFILE_JENKINS)enhances reliability.
Referencing a static constant helps avoid typos and ensures all references remain aligned.
35-35: Switch to explicit typeDocumentclarifies expectations forjobConfig.
This is consistent with the coding guidelines of improving readability and type safety.src/test/java/de/tum/cit/aet/artemis/core/authentication/InternalAuthenticationIntegrationTest.java (1)
94-94: Removal of thejenkinsServerparameter simplifies the mocking setup.
Ensure that all references tojenkinsServerin other testing utilities are also properly updated to avoid orphan code segments.src/test/java/de/tum/cit/aet/artemis/shared/architecture/module/AbstractModuleRepositoryArchitectureTest.java (1)
168-168: Restricting to Spring’s@Transactionalannotation enforces architectural consistency.
Make sure that no remaining references tojavax.transaction.Transactionalorjakarta.transaction.Transactionalneed to be migrated to Spring’s annotation.src/main/java/de/tum/cit/aet/artemis/core/config/Constants.java (1)
319-323: IntroducingPROFILE_JENKINSas a dedicated constant is a best practice.
This reduces reliance on hard-coded strings and unifies the application’s configuration approach.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsUserManagementService.java (9)
3-4: Good practice using a central profile constant for Jenkins.
This promotes maintainability and reduces the risk of typos.
45-45: Profile annotation looks good.
Switching to a constant for "jenkins" is consistent and improves clarity.
51-51: URI type usage is appropriate.
UsingURIinstead ofURLprovides better flexibility for path manipulations.
104-104: Validate constructed URIs.
Consider adding checks to handle malformed endpoints (e.g., missing segments).Would you like me to generate a script to look for any handling of malformed endpoints in the codebase?
156-156: Ensure endpoint parameters are sanitized.
Just a shared caution to guard against possible injection if user input is used in building these URIs.
244-244: Logging context is clear.
Usingmap(ProgrammingExercise::getProjectKey)is an elegant approach.
293-293: Informative log statement.
This consistent pattern for permission updates promotes maintainability.
321-322: Multi-line log usage is fine.
No issues found with splitting the statement into two lines.
396-396: Consistent pattern for JenkinsEndpoints.
This mirrors the CREATE/DELETE calls with a uniform approach.src/test/java/de/tum/cit/aet/artemis/core/authentication/UserJenkinsGitlabIntegrationTest.java (1)
69-69: Make sure old parameter usage is removed.
Removing the extra parameter simplifies the mocking approach.src/test/java/de/tum/cit/aet/artemis/core/connector/GitlabRequestMockProvider.java (1)
25-25: Import update seems intentional.
withSuccess()is more descriptive than the olderwithStatus(HttpStatus.OK).src/test/java/de/tum/cit/aet/artemis/exam/ExamIntegrationTest.java (1)
994-994: Parameter removal from mocking is consistent.
Ensures the new mocking flow only depends onjenkinsJobPermissionsService.src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java (5)
161-161: Fully qualified Javadoc reference looks good.
The switch to a fully qualified class reference helps prevent ambiguity when referencing classes from other packages.
703-703: Utilizing 'var' for improved readability.
This approach is clear and concise. No issues with type inference here.
1999-1999: No concerns with this loop.
The usage ofvarin the loop header is acceptable, and the logic for iterating overprogrammingExercisesis straightforward.
2016-2017: Assertion message is descriptive and clear.
Combining the.as(...)format with placeholders provides better debugging information. No issues found.
2314-2314: Consistent usage of local variable inference.
This is consistent with the style used throughout the test class.
...test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java
Show resolved
Hide resolved
|
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 pmd (7.8.0)src/main/java/de/tum/cit/aet/artemis/core/config/Constants.javaThe following rules are missing or misspelled in your ruleset file category/vm/bestpractices.xml: BooleanInstantiation, DontImportJavaLang, DuplicateImports, EmptyFinallyBlock, EmptyIfStmt, EmptyInitializer, EmptyStatementBlock, EmptyStatementNotInLoop, EmptySwitchStatements, EmptySynchronizedBlock, EmptyTryBlock, EmptyWhileStmt, ExcessiveClassLength, ExcessiveMethodLength, ImportFromSamePackage, MissingBreakInSwitch, SimplifyBooleanAssertion. Please check your ruleset configuration. src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.javaThe following rules are missing or misspelled in your ruleset file category/vm/bestpractices.xml: BooleanInstantiation, DontImportJavaLang, DuplicateImports, EmptyFinallyBlock, EmptyIfStmt, EmptyInitializer, EmptyStatementBlock, EmptyStatementNotInLoop, EmptySwitchStatements, EmptySynchronizedBlock, EmptyTryBlock, EmptyWhileStmt, ExcessiveClassLength, ExcessiveMethodLength, ImportFromSamePackage, MissingBreakInSwitch, SimplifyBooleanAssertion. Please check your ruleset configuration. src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.javaThe following rules are missing or misspelled in your ruleset file category/vm/bestpractices.xml: BooleanInstantiation, DontImportJavaLang, DuplicateImports, EmptyFinallyBlock, EmptyIfStmt, EmptyInitializer, EmptyStatementBlock, EmptyStatementNotInLoop, EmptySwitchStatements, EmptySynchronizedBlock, EmptyTryBlock, EmptyWhileStmt, ExcessiveClassLength, ExcessiveMethodLength, ImportFromSamePackage, MissingBreakInSwitch, SimplifyBooleanAssertion. Please check your ruleset configuration.
WalkthroughThis pull request introduces comprehensive modifications across multiple components of the Artemis project, with a primary focus on dependency management, Jenkins integration, and code refactoring. The changes span build configuration, service classes, test utilities, and integration tests. Key areas of modification include updating the Changes
Sequence DiagramsequenceDiagram
participant Client
participant JenkinsService
participant JenkinsJobService
participant RestTemplate
participant JenkinsEndpoints
Client->>JenkinsService: Request Build Plan
JenkinsService->>JenkinsJobService: Get Job Details
JenkinsJobService->>RestTemplate: Make HTTP Request
RestTemplate->>JenkinsEndpoints: Construct URI
JenkinsEndpoints-->>RestTemplate: Return Endpoint
RestTemplate-->>JenkinsJobService: Return Job Details
JenkinsJobService-->>JenkinsService: Return Job Information
JenkinsService-->>Client: Provide Build Plan Information
Possibly related PRs
Suggested Labels
Suggested Reviewers
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 using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (33)
src/test/java/de/tum/cit/aet/artemis/core/service/TelemetryServiceTest.java (1)
88-88: Consider removing the unused response.Here,
ExpectedCount.never()confirms the request should never be made; however,.andRespond(...)is still defined. For clarity, you can remove.andRespond(...)since it is never reached.- .andRespond(withSuccess().contentType(MediaType.APPLICATION_JSON).body(mapper.writeValueAsString("Success!")));src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInfoContributor.java (1)
24-24: Consider building URI paths more explicitly.
While string concatenation works, consider using aUriComponentsBuilderor a dedicated method for safer path and query construction.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseIntegrationJenkinsGitlabTest.java (1)
417-417: Duplicate mocking call.
Consider consolidating repeated mocks (lines 414 and 417) into a single method call to maintain DRY principles and reduce verbosity in tests.src/test/java/de/tum/cit/aet/artemis/exam/StudentExamIntegrationTest.java (5)
274-274: Simplify Jenkins mocking setupThe Jenkins mocking setup could be simplified by moving the
jenkinsJobPermissionsServiceparameter to a class-level field or using a builder pattern for better maintainability.- jenkinsRequestMockProvider.enableMockingOfRequests(jenkinsJobPermissionsService); + // Option 1: Use class field + @Autowired + private JenkinsJobPermissionsService jenkinsJobPermissionsService; + // In initTestCase: + jenkinsRequestMockProvider.enableMockingOfRequests(this.jenkinsJobPermissionsService); + // Option 2: Use builder pattern + jenkinsRequestMockProvider.builder() + .withJobPermissionsService(jenkinsJobPermissionsService) + .enableMockingOfRequests();
Line range hint
1115-1134: Add documentation for test helper methodsThe test helper methods like
createTestRun()andaddExamExerciseSubmissionsForUser()would benefit from clear documentation explaining their purpose, parameters, and return values. This would make the test class more maintainable and easier to understand.Add JavaDoc comments to document the helper methods:
+ /** + * Creates a test run for an exam. + * + * @return The created student exam test run + * @throws Exception if errors occur during test run creation + * @implNote The server invokes SecurityUtils.setAuthorizationObject() so after invoking + * this method you need to "login" the user again + */ private StudentExam createTestRun() throws Exception { testRunExam = examUtilService.addExam(course1); testRunExam = examUtilService.addTextModelingProgrammingExercisesToExam(testRunExam, false, true); return createTestRun(testRunExam); }
Line range hint
1583-1587: Consider splitting complex test methodsThe test method
testGradedStudentExamSummaryWithGradingScaleAsStudentAfterPublishResults()is quite long and tests multiple aspects. Consider splitting it into smaller, more focused test methods for better maintainability and readability.Split the test into multiple focused tests:
@Test void testGradedStudentExamSummaryBasicProperties() { // Test basic properties like maxPoints, maxBonusPoints, etc. } @Test void testGradedStudentExamSummaryStudentResult() { // Test student result properties } @Test void testGradedStudentExamSummaryAchievedPoints() { // Test achieved points per exercise }
Line range hint
1136-1147: Improve test data setup reusabilityThe test data setup in
createTestRun(Exam exam)could be made more reusable by extracting the hardcoded values into constants or configuration parameters.+ private static final int DEFAULT_WORKING_TIME = 6000; private StudentExam createTestRun(Exam exam) throws Exception { var instructor = userUtilService.getUserByLogin(TEST_PREFIX + "instructor1"); StudentExam testRun = new StudentExam(); testRun.setExercises(new ArrayList<>()); exam.getExerciseGroups().forEach(exerciseGroup -> testRun.getExercises().add(exerciseGroup.getExercises().iterator().next())); testRun.setExam(exam); - testRun.setWorkingTime(6000); + testRun.setWorkingTime(DEFAULT_WORKING_TIME); testRun.setUser(instructor);
Line range hint
2051-2055: Add verification for test cleanupThe test class could benefit from verifying that all test resources are properly cleaned up after each test. Consider adding assertions in the tearDown method.
@AfterEach void tearDown() throws Exception { programmingExerciseTestService.tearDown(); gitlabRequestMockProvider.reset(); jenkinsRequestMockProvider.reset(); + + // Verify cleanup + assertThat(studentRepos).allMatch(repo -> !repo.exists()); + assertThat(examSessionRepository.findAll()).isEmpty(); + assertThat(studentExamRepository.findAll()).isEmpty(); }src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanLinkInfoContributor.java (1)
24-24: Consider using URI building utilities for safety.String concatenation with
jenkinsServerUrimight cause an invalid URL if the URI doesn't end with a slash. Consider usingUriComponentsBuilderor another utility to ensure correctness.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionIntegrationTest.java (1)
213-213: Suggest centralizing repeated mocking calls
Multiple tests invoke similar mocking patterns. Consider extracting shared logic into a helper or setup method to improve DRY principles and maintainability.src/test/java/de/tum/cit/aet/artemis/programming/AbstractProgrammingIntegrationJenkinsGitlabTest.java (1)
3-3: Consider removing unused imports or renaming for consistency.Currently, there is both
import java.net.URI;andimport java.net.URL;. The importURLremains necessary forgitlabServerUrl, but you might want to renamegitlabServerUrltogitlabServerUrifor consistency across code references if both are intended to handle similar server endpoints.src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java (1)
199-199: Clarify the purpose of passingnulltomockGetFolderJob.Passing
nullcould indicate either no folder or a special default. If it truly implies a default scenario, consider adding a short comment to clarify the implications of this call.src/main/java/de/tum/cit/aet/artemis/programming/service/gitlab/GitLabPersonalAccessTokenManagementService.java (1)
Line range hint
164-168: Consider centralized URI building for maintainability.These queries for
searchanduser_idare straightforward, but you might benefit from a small utility or static factory method to build commonly used GitLab API URIs. It fosters consistency and prevents errors if the base path changes.src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java (1)
1999-1999: Consider renaming the local variable for clarity.The variable name
noGeneratedParticipationscan be improved to something more descriptive, such asgeneratedParticipationsCount, to better convey the purpose.- int noGeneratedParticipations = ExamPrepareExercisesTestUtil.prepareExerciseStart(request, exam, course); + int generatedParticipationsCount = ExamPrepareExercisesTestUtil.prepareExerciseStart(request, exam, course);src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsService.java (3)
170-171: UseUriComponentsBuilderto reduce potential SSRF risks.
The TODO comment suggests migrating from string concatenation toUriComponentsBuilder. This is advisable to ensure robust URL handling and mitigate SSRF or path injection risks when user-controlled variables are appended.
201-207:checkIfProjectExistsreturning plain-text message.
Returning a descriptive string is acceptable, but consider standardizing error handling or using dedicated exceptions/messages for consistency across the service layer.
249-249: Folder creation exception handling.
Catching a broadExceptioncan obscure the root cause. Consider narrowing it down or adding more context in the log statement for improved maintainability.Also applies to: 251-251
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java (7)
53-63:getJobmethod
This method handles missing or invalid parameters gracefully. TheNotFoundcatch is a nice fallback, but consider logging at debug or trace level for non-critical warnings if job absence is a normal scenario.Also applies to: 67-67
91-97:getFolderJobhandling
Returning null if the folder does not exist is consistent with similar patterns. Emphasize consistent error messages or exceptions if needed for uniform error handling.
110-119:getJobConfigmethod
Replacing references to master/main is done in-line. Be sure to handle more branches if needed. This also suggests the method modifies the raw XML, which can be fragile if Jenkins changes internal logic.Also applies to: 126-130
144-149:getFolderConfigmethod
Returns null if the folder is missing. The logic is straightforward, but consider if a specialized exception is more appropriate than null to highlight a missing folder.
184-196:createJobInFoldermethod
Checks for existing job and folder. The approach is robust, but watch for concurrency: if two users create the same job name concurrently, you may race.Also applies to: 197-199
206-232:updateJobmethod
CatchingNotFoundand rethrowing aJenkinsExceptionis consistent. Could be extended to retry logic if job creation is slow or intermittent.
236-253:updateFolderJob
Folder updates are handled similarly to job updates. The pattern is consistent, thoughIOExceptionmight be too broad. Consider a custom exception or decompress logs for better debug.src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.java (1)
125-138:mockCreateProjectForExercise
Simulates folder creation effectively. Consider coverage for concurrency or repeated calls in a real scenario.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsEndpoints.java (1)
3-3: Use narrower imports if possible.Consider importing only the required classes from
java.net, such asURI, to adhere to best practices around minimal imports.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsAuthorizationInterceptor.java (1)
27-27: Profile annotation approach.Retaining the
@Profile(PROFILE_JENKINS)annotation is appropriate here. Just ensure other Jenkins-related classes use the same constant for consistency.src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.java (1)
17-27: Documentation accurately illustrates usage of path segments and arguments.
Clear examples help future maintainers grasp how the method processes variable segments.src/main/java/de/tum/cit/aet/artemis/core/config/Constants.java (1)
319-323: Clarify the Javadoc to match the Jenkins profile usage.
The Javadoc line at 320 suggests a local CI setup, but this constant is specifically for the Jenkins profile. Consider revising the comment for accuracy.Apply this patch to correct the doc comment:
- * The name of the Spring profile used to process build jobs in a local CI setup. + * The name of the Spring profile used to process build jobs in Jenkins.src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsServiceTest.java (2)
164-167: Reduce duplication in multiple “mockCopyBuildPlan” invocations.
Lines 164–167 appear similar to lines 183–186. Consider extracting the repeated logic into a helper method.
183-186: Refactor repeated plan-copy mocking logic.
As noted above for lines 164–167, these calls look duplicated. Please refactor to maintain DRY principles.build.gradle (2)
Line range hint
98-148: Excellent work on dependency cleanup!The comprehensive exclusion of unnecessary dependencies, particularly those with security implications (jasypt, xstream) and unused transitive dependencies, helps reduce the attack surface and potential vulnerabilities.
Consider documenting these exclusions in a separate file (e.g.,
gradle/dependency-management.gradle) to improve maintainability, as the list of exclusions might grow over time.
459-462: Consider enabling the unused-dependency rule.The 'dependency-parentheses' rule is good for consistency, but enabling the commented-out 'unused-dependency' rule would help maintain a lean dependency set by failing the build when unused dependencies are detected.
gradleLint { rules = ['dependency-parentheses'] -// criticalRules = ['unused-dependency'] // <-- this will fail the build in the event of a violation + criticalRules = ['unused-dependency'] }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (6)
.idea/runConfigurations/Artemis__Server__LocalVC___Jenkins_.xmlis excluded by!**/*.xmllibs/jenkins-client-0.4.1.jaris excluded by!**/*.jar,!**/*.jarsrc/main/kubernetes/artemis/secrets/artemis-secrets.ymlis excluded by!**/*.ymlsrc/main/resources/config/application-artemis.ymlis excluded by!**/*.ymlsrc/main/resources/config/application.ymlis excluded by!**/*.ymlsrc/test/resources/config/application-artemis.ymlis excluded by!**/*.yml
📒 Files selected for processing (63)
build.gradle(11 hunks)src/main/java/de/tum/cit/aet/artemis/core/config/Constants.java(1 hunks)src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.java(5 hunks)src/main/java/de/tum/cit/aet/artemis/core/config/connector/JenkinsServerConfiguration.java(0 hunks)src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.java(3 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/InternalUrlService.java(1 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/aeolus/AeolusBuildPlanService.java(0 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/gitlab/GitLabPersonalAccessTokenManagementService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsAuthorizationInterceptor.java(4 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsEndpoints.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInfoContributor.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInternalUrlService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsResultService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsService.java(9 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsTriggerService.java(1 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsUserManagementService.java(8 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanCreator.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanLinkInfoContributor.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanService.java(11 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobPermissionsService.java(2 hunks)src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java(6 hunks)src/test/java/de/tum/cit/aet/artemis/core/authentication/InternalAuthenticationIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/core/authentication/UserJenkinsGitlabIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/core/connector/AeolusRequestMockProvider.java(3 hunks)src/test/java/de/tum/cit/aet/artemis/core/connector/GitlabRequestMockProvider.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.java(11 hunks)src/test/java/de/tum/cit/aet/artemis/core/service/TelemetryServiceTest.java(4 hunks)src/test/java/de/tum/cit/aet/artemis/core/user/AccountResourceWithGitLabIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exam/ExamIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exam/ExamParticipationIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exam/ExamUserIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exam/StudentExamIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/exercise/participation/ParticipationIntegrationTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/exercise/service/ParticipationServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/lecture/LectureUnitServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/modeling/apollon/ApollonConversionServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/AbstractProgrammingIntegrationJenkinsGitlabTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ConsistencyCheckGitlabJenkinsIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ContinuousIntegrationTestService.java(3 hunks)src/test/java/de/tum/cit/aet/artemis/programming/CourseGitlabJenkinsIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseGitlabJenkinsIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseIntegrationJenkinsGitlabTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTemplateIntegrationTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionAndResultGitlabJenkinsIntegrationTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionIntegrationTest.java(8 hunks)src/test/java/de/tum/cit/aet/artemis/programming/RepositoryProgrammingExerciseParticipationJenkinsIntegrationTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusBuildScriptGenerationServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusTemplateResourceTest.java(0 hunks)src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsAuthorizationInterceptorTest.java(2 hunks)src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobPermissionServiceTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobServiceTest.java(3 hunks)src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsServiceTest.java(8 hunks)src/test/java/de/tum/cit/aet/artemis/programming/util/MockDelegate.java(0 hunks)src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java(6 hunks)src/test/java/de/tum/cit/aet/artemis/shared/architecture/module/AbstractModuleRepositoryArchitectureTest.java(1 hunks)src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationGitlabCIGitlabSamlTest.java(0 hunks)src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationIndependentTest.java(0 hunks)src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java(4 hunks)src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationLocalCILocalVCTest.java(0 hunks)
💤 Files with no reviewable changes (7)
- src/main/java/de/tum/cit/aet/artemis/core/config/connector/JenkinsServerConfiguration.java
- src/test/java/de/tum/cit/aet/artemis/programming/util/MockDelegate.java
- src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationGitlabCIGitlabSamlTest.java
- src/main/java/de/tum/cit/aet/artemis/programming/service/aeolus/AeolusBuildPlanService.java
- src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationIndependentTest.java
- src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusTemplateResourceTest.java
- src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationLocalCILocalVCTest.java
✅ Files skipped from review due to trivial changes (1)
- src/test/java/de/tum/cit/aet/artemis/exam/ExamParticipationIntegrationTest.java
🧰 Additional context used
📓 Path-based instructions (54)
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/InternalUrlService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/core/authentication/InternalAuthenticationIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsAuthorizationInterceptorTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/gitlab/GitLabPersonalAccessTokenManagementService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseGitlabJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/exercise/service/ParticipationServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsTriggerService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInternalUrlService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/core/connector/AeolusRequestMockProvider.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/service/TelemetryServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/exam/ExamUserIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/authentication/UserJenkinsGitlabIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ConsistencyCheckGitlabJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/core/config/Constants.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ContinuousIntegrationTestService.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/AbstractProgrammingIntegrationJenkinsGitlabTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobPermissionServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseIntegrationJenkinsGitlabTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/CourseGitlabJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/shared/architecture/module/AbstractModuleRepositoryArchitectureTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanLinkInfoContributor.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/connector/GitlabRequestMockProvider.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/modeling/apollon/ApollonConversionServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInfoContributor.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanCreator.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/exercise/participation/ParticipationIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/exam/ExamIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsAuthorizationInterceptor.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionAndResultGitlabJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/user/AccountResourceWithGitLabIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsUserManagementService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusBuildScriptGenerationServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTemplateIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/lecture/LectureUnitServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/programming/RepositoryProgrammingExerciseParticipationJenkinsIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsResultService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/exam/StudentExamIntegrationTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsEndpoints.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusServiceTest.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.java (1)
Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobPermissionsService.java (1)
Pattern src/main/java/**/*.java: naming:CamelCase; principles:{single_responsibility,small_methods,no_duplication}; db:{perf_queries,datetime_not_timestamp}; rest:{stateless,singleton,delegate_logic,http_only,minimal_dtos}; dtos:{java_records,no_entities,min_data,single_resp}; di:constructor_injection; kiss:simple_code; file_handling:os_indep_paths; practices:{least_access,avoid_transactions,code_reuse,static_member_ref,prefer_primitives}; sql:{param_annotation,uppercase,avoid_subqueries};java:avoid_star_imports
📓 Learnings (2)
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java (2)
Learnt from: magaupp
PR: ls1intum/Artemis#8802
File: src/main/java/de/tum/in/www1/artemis/service/connectors/jenkins/JenkinsProgrammingLanguageFeatureService.java:43-43
Timestamp: 2024-11-12T12:51:58.050Z
Learning: Jenkins support for Rust was added in commit d0fb7032e70c001dc8b2c4d0a391ca8bf7e7d586.
Learnt from: magaupp
PR: ls1intum/Artemis#9256
File: src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java:0-0
Timestamp: 2024-11-12T12:52:03.805Z
Learning: In `JenkinsProgrammingLanguageFeatureService.java`, comments explaining boolean flags in calls to the `ProgrammingLanguageFeature` constructor are unnecessary because the parameter names are clear, and most IDEs display them as inline hints.
src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java (1)
Learnt from: magaupp
PR: ls1intum/Artemis#9751
File: src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseFactory.java:143-148
Timestamp: 2024-11-26T20:43:17.588Z
Learning: In `src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseFactory.java`, the test package name assigned in `populateUnreleasedProgrammingExercise` does not need to adhere to naming conventions.
🔇 Additional comments (212)
src/test/java/de/tum/cit/aet/artemis/core/service/TelemetryServiceTest.java (3)
9-9: No issues with the new import.Switching to
withSuccess()is consistent with testing a general success response, so this change is fine.
64-64: Good approach to simplify response creation.Replacing
withStatus(HttpStatus.OK)withwithSuccess()ensures a concise and readable test setup.
76-76: Clearer expression of a successful mock response.The
withSuccess()method more clearly communicates the intended success scenario.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInfoContributor.java (4)
3-4: Good use of constants.
UsingPROFILE_JENKINSfrom a central constants file improves maintainability and consistency.
5-5: Migrating to URI is consistent with standard best practices.
Usingjava.net.URIis more robust for future expansions such as adding paths or query parameters.
16-16: Profile annotation is well-defined.
Leveraging the named constant for the profile ensures consistency across the codebase.
20-20: Field renaming enhances clarity.
Renaming the field fromJENKINS_SERVER_URLtojenkinsServerUribetter conveys the usage ofURI.src/test/java/de/tum/cit/aet/artemis/core/user/AccountResourceWithGitLabIntegrationTest.java (1)
36-36: Ensure comprehensive test coverage after removing Jenkins server references.Removing the
jenkinsServerparameter and only mockingjenkinsJobPermissionsServiceis consistent with the PR objective of eliminating the Jenkins client. Just verify that all Jenkins-related requests are still covered by the tests and confirm that the new direct REST calls are thoroughly tested.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionAndResultGitlabJenkinsIntegrationTest.java (1)
49-49: Confirm complete removal ofjenkinsServerreferences.Removing the
jenkinsServerparameter aligns with the plan to migrate away from the Jenkins client. Please verify that all references to the now-unusedjenkinsServerhave been deleted throughout the code, ensuring no residual dependencies or calls exist.✅ Verification successful
Based on the search results, I can see that
jenkinsServeris not present in any of the files. Instead, there are occurrences ofjenkinsServerUriwhich is a different variable used for storing the Jenkins server URL. The original review comment was concerned about the removal ofjenkinsServerparameter, but the search results confirm that there are no remaining references to this specific parameter in the codebase.The removal of
jenkinsServerparameter is complete and safe.The search results show that the codebase consistently uses
jenkinsServerUrifor Jenkins server URL-related operations, and there are no lingering references to the removedjenkinsServerparameter. This confirms that the migration away from the Jenkins client has been properly handled for this specific parameter.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search the entire codebase for references to jenkinsServer rg -A 3 "jenkinsServer"Length of output: 34575
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseGitlabJenkinsIntegrationTest.java (1)
55-55: Confirm complete removal ofjenkinsServerreferences.This updated method signature reflects the removal of the Jenkins client. As a precaution, ensure there are no remaining references to
jenkinsServeracross the codebase.✅ Verification successful
jenkinsServerreferences have been replaced withjenkinsServerUriThe search results show that there are no direct references to
jenkinsServerin the codebase. Instead, all Jenkins-related components are usingjenkinsServerUrifor server URI handling. This is consistent with the refactoring to remove the Jenkins client.Key observations from the search:
- All occurrences are of
jenkinsServerUri, which is the correct URI-based approach- Used consistently across test and main code for endpoint construction
- No legacy
jenkinsServerreferences found🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that the 'jenkinsServer' variable is no longer referenced throughout the codebase. rg jenkinsServerLength of output: 10840
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseIntegrationJenkinsGitlabTest.java (2)
32-32: Jenkins client references successfully removed.
This change simplifies the test setup by removing the obsoletejenkinsServerparameter, aligning with the strategy to use the Jenkins REST API directly.
414-414: Smoother test mocking approach.
Removing the extra boolean parameter clarifies the test's intention without sacrificing clarity or coverage.src/test/java/de/tum/cit/aet/artemis/exam/ExamIntegrationTest.java (1)
994-994: Removal of jenkinsServer parameter looks good.
This updated call aligns with the PR objective to remove the Jenkins client. Ensure that all references tojenkinsServer(if any remain) are consistently removed throughout the tests.src/test/java/de/tum/cit/aet/artemis/core/authentication/InternalAuthenticationIntegrationTest.java (1)
94-94: Refactoring aligns with removing Jenkins client references.This change correctly removes the unneeded
jenkinsServerparameter, aligning with the PR's objective to eliminate Jenkins client usage. Ensure there are no remaining references tojenkinsServerin the codebase.Use the following script to confirm:
✅ Verification successful
Remaining Jenkins references are part of the Jenkins-specific services
The search results show that all remaining references to
jenkinsServerare within Jenkins-specific service classes and their corresponding test files, which is expected. These references are part of:
- Jenkins service implementations (e.g.,
JenkinsUserManagementService,JenkinsService)- Jenkins-related test utilities (e.g.,
JenkinsRequestMockProvider)- Jenkins integration test classes (e.g.,
AbstractProgrammingIntegrationJenkinsGitlabTest)The removal of the
jenkinsServerparameter from the test class is correct and aligns with the PR's objective, while the remaining references are in their proper context within Jenkins-specific components.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search the codebase for any remaining references to `jenkinsServer`. rg "jenkinsServer"Length of output: 10840
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTest.java (2)
53-53: Smooth transition to direct Jenkins requestsThis change from the old Jenkins client parameter to
jenkinsJobPermissionsServiceinenableMockingOfRequestsaligns with the PR’s goal of removing Jenkins client usage.
174-174: Consistent Jenkins request mocking setupSimilar to the previous change, this approach simplifies the test by utilizing
jenkinsJobPermissionsServiceinstead of the old Jenkins client parameter. This ensures a more cohesive mocking strategy across the test suite.src/test/java/de/tum/cit/aet/artemis/exam/StudentExamIntegrationTest.java (1)
Line range hint
1-2051: LGTM! Comprehensive test coverageThe test class provides thorough coverage of student exam functionality with well-structured test methods and appropriate assertions. The tests verify important business logic and edge cases.
src/test/java/de/tum/cit/aet/artemis/programming/ConsistencyCheckGitlabJenkinsIntegrationTest.java (1)
13-13: **Remove references to jenkinsServer across the codebase **This change aligns with the PR objective of removing the Jenkins client and directly accessing the Jenkins REST API. Please verify that any remaining references to
jenkinsServerhave been fully removed or refactored throughout the codebase to avoid potential inconsistencies.src/test/java/de/tum/cit/aet/artemis/programming/CourseGitlabJenkinsIntegrationTest.java (1)
32-32: Confirm removal ofjenkinsServerparameter usageGood job simplifying the method call. Ensure that all references to the old
enableMockingOfRequests(jenkinsServer, ...)signature have been updated accordingly throughout the test codebase.✅ Verification successful
Based on the search results, I can see that all occurrences of
enableMockingOfRequestsin the test files are using either the new signature withjenkinsJobPermissionsServiceparameter or no parameters at all (for other mock providers). There are no instances of the old signature withjenkinsServerparameter.All references to
enableMockingOfRequestshave been properly updatedThe codebase shows consistent usage of the new signature
enableMockingOfRequests(jenkinsJobPermissionsService)for Jenkins mock provider across all test files. No references to the old signature containingjenkinsServerparameter were found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that no references to the old signature remain in test files. rg -A 3 "enableMockingOfRequests" src/test/javaLength of output: 44158
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanLinkInfoContributor.java (4)
3-4: Use of a static constant for the @Profile annotation looks good.Replacing hard-coded strings with a constant improves maintainability and reduces the chance of typing mistakes.
5-5: Switching to URI is appropriate.Using
URIinstead ofURLis a good practice for better representation of resource identifiers.
16-16: @Profile annotation with PROFILE_JENKINS is consistent.This improves code consistency by leveraging a central definition of the Jenkins profile.
20-20: Use of URI for jenkinsServerUri is valid.Moving from
URLtoURIhere aligns with best practices for URI references in Java.src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusBuildScriptGenerationServiceTest.java (3)
35-35: Good practice: Restricting field visibility to private.Switching
restTemplateto private helps reinforce encapsulation.
38-38: Good practice: Restricting field visibility to private.Switching
aeolusBuildPlanServiceto private helps maintain proper test scoping.
41-41: Good practice: Restricting field visibility to private.Limiting direct access to
aeolusBuildScriptGenerationServicealso supports test encapsulation.src/test/java/de/tum/cit/aet/artemis/programming/aelous/AeolusServiceTest.java (4)
51-51: Good practice: Restricting field visibility to private.Making
restTemplateprivate upholds proper test encapsulation.
57-57: Good practice: Restricting field visibility to private.Limiting access to
aeolusBuildPlanServicehelps modularize the test.
60-60: Good practice: Restricting field visibility to private.Adjusting
aeolusTemplateServiceto private aligns with the principle of least privilege for test fields.
63-63: Good practice: Restricting field visibility to private.Making
aeolusBuildScriptGenerationServiceprivate is consistent and improves test maintainability.src/test/java/de/tum/cit/aet/artemis/core/connector/AeolusRequestMockProvider.java (4)
7-7: Import alignment is correct
The import ofwithSuccessaligns well with the usage in the methods below and ensures consistent mocking responses.
76-76: Usage ofwithSuccess()is a clean replacement
Switching fromwithStatus(HttpStatus.OK)towithSuccess()makes the intent clearer and simplifies the test code.
114-114: Consistent usage ofwithSuccess()
UsingwithSuccess()consistently across mocked responses is a solid practice, enhancing uniformity in testing.
118-118: Bearer token check withwithSuccess()
The new approach cleanly validates the presence of the authorization header before returning a successful response. Nicely done.src/test/java/de/tum/cit/aet/artemis/core/connector/GitlabRequestMockProvider.java (2)
25-25: Import forwithSuccess()
This import follows the same streamlined approach used elsewhere for mocking successful responses.
369-369: Streamlined mock response withwithSuccess()
ReplacingwithStatus(HttpStatus.OK)withwithSuccess()reduces verbosity and improves readability in mocked responses.src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobPermissionServiceTest.java (1)
31-31: The removal of the jenkinsServer parameter is aligned with the PR's objective.Please verify that the codebase no longer relies on the old parameter wherever Jenkins interactions occur.
✅ Verification successful
Based on the search results, I can see that
jenkinsServeris now replaced withjenkinsServerUrithroughout the codebase, which is consistently used in all Jenkins-related services and tests. The parameter removal is properly aligned with this change, and there are no lingering references to the oldjenkinsServerparameter.The codebase has been properly updated to use
jenkinsServerUriconsistently.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search the codebase for any remaining references to `jenkinsServer` rg -A 3 $'jenkinsServer'Length of output: 34575
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsJobServiceTest.java (8)
26-26: New import for JenkinsJobService is appropriate.
No concerns. It's consistent with the new direct Jenkins interactions via the REST API.
41-41: Enabling mock requests with jenkinsJobPermissionsService
The updated call ensures consistent mocking of Jenkins requests for permission checks. This looks correct and aligns with the test's objectives.
63-64: Use of local variable for job details
Defining a localvar joband then passing it to the mock call is clear and concise. No issues found.
67-68: Verifying mock interactions
Replacing numerous individual verifies with a singleverifyMocks()method is neat and keeps the test concise. Just be sure that all relevant calls are validated internally byverifyMocks().
74-75: Mocking scenario where job does not exist
ReturningnullformockGetJobis a valid approach to simulate a non-existent job. No issues found.
78-79: Verifying correct job creation flow
UsingverifyMocks()again ensures consistent testing for the newly created job scenario. Implementation looks correct.
85-85: Mocking job creation in folder to trigger JenkinsException
UsingmockCreateJobInFolderis aligned with the updated approach. The test effectively checks behavior on transformation exceptions.
92-92: Checking for JenkinsException instead of IOException
Switching fromIOExceptiontoJenkinsExceptionis consistent with the new error-handling approach in the direct REST usage. The updated assertion aligns with the intended exception flow.src/test/java/de/tum/cit/aet/artemis/core/authentication/UserJenkinsGitlabIntegrationTest.java (1)
69-69: Confirm that removal ofjenkinsServerparameter doesn't break related mocks or references.This change moves away from passing the Jenkins server to directly using the
jenkinsJobPermissionsService. Please ensure that remaining references tojenkinsServer(if any) have been removed or updated across the test suite to prevent broken mocks.✅ Verification successful
Based on the search results, I can see that
jenkinsServeris not used as a parameter or variable in any of the test files. Instead, all Jenkins-related services and tests usejenkinsServerUriwhich is injected via@Value("${artemis.continuous-integration.url}"). The removal of thejenkinsServerparameter from the test method is safe as there are no references to it in the codebase.The removal of
jenkinsServerparameter is safe and doesn't impact any mocks or references.The codebase consistently uses
jenkinsServerUrifor Jenkins server configuration, and the test infrastructure is built around mocking HTTP requests to Jenkins endpoints rather than using a Jenkins server instance directly.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Searching for the term 'jenkinsServer' throughout the codebase outside this file rg --context 3 'jenkinsServer'Length of output: 54760
src/test/java/de/tum/cit/aet/artemis/lecture/LectureUnitServiceTest.java (1)
47-47: Good use of localized scope for thelecturevariable.By moving
lecturefrom a class-level field to a local variable withininit(), you reduce potential side effects and improve code clarity. Make sure there are no remaining references to the oldlecturefield anywhere else in the code.Here's a script to confirm all references to the old
private Lecture lecture;were removed:✅ Verification successful
Let me verify if there are any references to the old
lecturefield in the test file under review.
The class-level
lecturefield has been successfully removed from LectureUnitServiceTestThe verification confirms that:
- There is no class-level
private Lecture lecturefield in LectureUnitServiceTest.java- The
lecturevariable is now properly scoped within theinit()method- All references to
lecturewithin the test file are using the locally scoped variable🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for references to the old class-level `lecture` field. rg -A 5 'private Lecture lecture;'Length of output: 5651
Script:
#!/bin/bash # Search for any references to lecture in LectureUnitServiceTest.java rg -U "lecture" "src/test/java/de/tum/cit/aet/artemis/lecture/LectureUnitServiceTest.java"Length of output: 2416
src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingSubmissionIntegrationTest.java (7)
98-98: Consistent update to direct REST usage
Removing the Jenkins server parameter in favor of usingjenkinsJobPermissionsServicedirectly simplifies the mocking strategy and aligns well with the new REST-based approach.
138-138: Good move towards uniform Jenkins handling
By eliminating the Jenkins server parameter, the code relies on a single entry point for mock setup, promoting clarity and reducing overhead.
169-169: Cohesive exception handling
Combining the removal of the Jenkins server parameter with thedoThrowmechanism forgitServiceis coherent. The refactoring neatly handles the test scenario for missing commit hashes.
285-285: Removal of redundant parameters
Dropping the server parameter here matches the broader strategy, further reducing coupling in test setup.
363-363: Testing synergy with Jenkins
UsingjenkinsJobPermissionsServicerather than a Jenkins server reference keeps the focus on permission-based features while retaining accurate test coverage.
396-396: Check broader mocking consistency
This change ensures Jenkins requests are uniformly mocked across all tests. Verify that removing the Jenkins server parameter does not affect other concurrency or error-handling scenarios.
433-433: Uniform approach to Jenkins mocking
Consistently usingjenkinsRequestMockProvider.enableMockingOfRequests(jenkinsJobPermissionsService)removes duplication and avoids confusion about server references throughout the test suite.src/test/java/de/tum/cit/aet/artemis/programming/ProgrammingExerciseTemplateIntegrationTest.java (2)
207-207: Consistent cleanup in tearDownRepeating the updated call to
enableMockingOfRequestswithout thejenkinsServerparameter ensures consistency in the teardown logic for tests. Looks good.
193-193: Good removal of jenkinsServer parameterBy removing the Jenkins client references and relying solely on
jenkinsJobPermissionsService, you align with the PR's objective to directly use the Jenkins REST API. This simplification of the mocking setup is good.Here is a suggested script to confirm no stale references to
jenkinsServerremain in the codebase:✅ Verification successful
No stale references to
jenkinsServerfound, butjenkinsServerUriis still in useThe search results show that while there are no direct references to the removed
jenkinsServerparameter, there are numerous uses ofjenkinsServerUrithroughout the codebase. However, this is expected and correct because:
jenkinsServerUriis a configuration property used to specify the base URL for Jenkins REST API calls- It's used consistently across services to construct endpoint URLs for various Jenkins operations
- This is different from the removed
jenkinsServerparameter which was likely a client instanceLet's verify there are no remaining references to the actual Jenkins client:
The removal of
jenkinsServerparameter is clean and correctThe codebase analysis confirms that:
- There are no remaining references to the removed
jenkinsServerparameter- The only Jenkins client-related code found is the
JenkinsAuthorizationInterceptorwhich is a Spring HTTP client interceptor for REST API authentication, not related to the old Jenkins client- The use of
jenkinsServerUrithroughout the codebase is correct as it's needed for constructing REST API endpointsThe changes align perfectly with the PR's objective to use Jenkins REST API directly instead of a client library. The removal of the parameter is clean and doesn't leave any technical debt.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for any references to jenkinsServer throughout the repository rg "jenkinsServer" -A 3Length of output: 34575
Script:
#!/bin/bash # Search for Jenkins client related imports and class references rg -i "jenkins.*client|com\.offbytwo\.jenkins" -g "*.java"Length of output: 954
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsAuthorizationInterceptorTest.java (2)
119-119: URI construction aligned with new Jenkins approach.Switching to
jenkinsServerUrifor crumb retrieval is consistent with removing the Jenkins client. This direct reference helps reduce dependencies and potential mismatch issues.
42-42: Ensure no leftover references tojenkinsServer.Good move removing
jenkinsServerfrom this test setup, in line with direct REST API usage. Verify there are no remaining references tojenkinsServeracross the codebase to avoid confusion or inconsistent behavior.Use this script to confirm no legacy references linger:
✅ Verification successful
All references to
jenkinsServerhave been replaced withjenkinsServerUriBased on the search results, the codebase has been fully migrated from using
jenkinsServertojenkinsServerUri. The search shows that all occurrences of "jenkinsServer" in the codebase are now using the newjenkinsServerUrivariable name, which is consistent with the direct REST API usage approach. No legacy references to the oldjenkinsServervariable remain.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Locate any references to jenkinsServer that might remain in the codebase rg 'jenkinsServer' -A 3Length of output: 34575
src/test/java/de/tum/cit/aet/artemis/exam/ExamUserIntegrationTest.java (1)
110-110: Check references tojenkinsServeracross the codebase.This new invocation of
enableMockingOfRequestsno longer includes thejenkinsServerparameter. Ensure all other references tojenkinsServerfor mocking have also been removed or adapted for consistency.Use the following script to locate any remaining mentions of
jenkinsServer:✅ Verification successful
Let me analyze the references to
jenkinsServerin the codebase to verify the concern.
Let me analyze the usage pattern of
enableMockingOfRequestsin the codebase.
Based on the analysis of the codebase, I can now provide the final response:
The removal of
jenkinsServerparameter is correct and consistentThe
enableMockingOfRequestsmethod inJenkinsRequestMockProviderhas been properly updated to only require thejenkinsJobPermissionsServiceparameter. This change is consistent across the codebase as:
- All test files are using the updated signature correctly
- The
jenkinsServerUriis now handled internally within theJenkinsRequestMockProviderclass as a field- Other mock providers (
GitlabRequestMockProvider,AeolusRequestMockProvider, etc.) follow a similar pattern where server/URI configuration is handled internally🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for references to jenkinsServer across the repository rg "jenkinsServer"Length of output: 10840
Script:
#!/bin/bash # Search for enableMockingOfRequests to understand its usage pattern rg "enableMockingOfRequests" -A 2Length of output: 34935
Script:
#!/bin/bash # Search for the implementation of enableMockingOfRequests in JenkinsRequestMockProvider ast-grep --pattern 'public void enableMockingOfRequests($$$) { $$$ }'Length of output: 5472
src/test/java/de/tum/cit/aet/artemis/programming/AbstractProgrammingIntegrationJenkinsGitlabTest.java (1)
69-69: Ensure references to the oldjenkinsServerUrlare fully updated.While the switch from
URLtoURIis correct, verify that no references remain tojenkinsServerUrlelsewhere in the codebase. This helps avoid confusion or compilation errors.✅ Verification successful
All references are using the new
jenkinsServerUrivariableBased on the search results, there are no remaining references to the old
jenkinsServerUrlvariable in the codebase. All occurrences found are using the newjenkinsServerUrivariable consistently across test and main source files. The migration from URL to URI appears to be complete and consistent.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find references to the old jenkinsServerUrl variable across the repository. rg "jenkinsServerUrl"Length of output: 21
Script:
#!/bin/bash # Let's try a case-insensitive search and also look for similar patterns rg -i "jenkins.*server.*url" # Also search for the new URI variable name to understand the context rg "jenkinsServerUri" # Let's also check git history for any recent changes related to this git log --grep="jenkins.*server.*url" -i --since="3 months ago"Length of output: 10874
src/main/java/de/tum/cit/aet/artemis/programming/service/InternalUrlService.java (1)
107-108: Consider validating the URI scheme when usingfromUriString
By switching fromfromHttpUrltofromUriString, the builder may accept non-http/https or potentially invalid schemes, which can cause errors further downstream. Consider adding a validation step or a fallback for unexpected schemes to ensure robustness.src/test/java/de/tum/cit/aet/artemis/shared/base/AbstractSpringIntegrationJenkinsGitlabTest.java (6)
102-102: Confirm partial reset approach.Here, the reset call removes all recorded interactions on
continuousIntegrationServiceandversionControlService, but omits other injected spy beans (e.g.,jenkinsJobPermissionsService). Verify whether this selective approach is intentional or if additional spy beans need resetting for consistent test isolation.
201-201: Verify repeated call tomockGetFolderJob.There's a second call to
mockGetFolderJob(targetProjectKey)immediately after line 199. Double-check that calling it twice is needed. If the second call overwrites or duplicates the first call, consider removing one to keep tests concise.
202-203: Refactors for plan copying are consistent with new Jenkins approach.Switching to the more explicit
mockCopyBuildPlanFromTemplateandmockCopyBuildPlanFromSolutionis a good refactoring step. Ensure that template- vs. solution-based distinctions remain correct for all build plan copies.
323-323: Confirm argument consistency for copying build plans.Passing the same
projectKeyfor bothsourceProjectandtargetProjectmay be correct if they’re the same project. If this is intended to copy from the same project, add a short clarifying comment; otherwise, ensure the correct source key is passed.
438-438: Ensure group membership handling is valid for single-group additions.Using
Set.of(group)is a neat approach. Verify that the underlying method can handle single-group logic without inadvertently requiring multiple groups or overwriting existing memberships.
445-445: Re-check logic for adding the user to a group after removal.Calling
mockAddUsersToGroupsright aftermockRemoveUserFromGroupscan cause confusion. If it’s intentional to re-add the same user, consider adding clarifying comments or reordering these actions to avoid accidental readmission.src/test/java/de/tum/cit/aet/artemis/exercise/service/ParticipationServiceTest.java (1)
101-101: Removal of redundantjenkinsServerparameter looks good.This simplification aligns with the PR goal of removing the Jenkins client and interacting directly via REST. Ensure there are no other references to
jenkinsServeror unused imports/fields in your codebase.You can run the following script to confirm that no references to
jenkinsServerremain outside this test:✅ Verification successful
All references to
jenkinsServerhave been replaced with REST-based interactionsThe search results confirm that all occurrences of
jenkinsServerin the codebase are now using the REST-based approach withjenkinsServerUri. The references found are part of the new implementation that uses direct REST calls instead of the Jenkins client.Key observations:
- All occurrences are using
jenkinsServerUrifor REST endpoints- No legacy
jenkinsServerreferences remain- Changes are consistent with the PR's goal of removing Jenkins client dependency
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that no other references to jenkinsServer remain in the codebase rg -A 3 'jenkinsServer'Length of output: 34575
src/main/java/de/tum/cit/aet/artemis/programming/service/gitlab/GitLabPersonalAccessTokenManagementService.java (1)
151-153: Confirm correct handling of base URL concatenation.Switching from
fromHttpUrltofromUriStringis fine. However, ensure there's no trailing slash ingetGitLabServerUrl(). A double slash might form and cause potential 404 or 301 issues.Please run the following script to verify there's no trailing slash in the server URLs:
✅ Verification successful
Let me check the implementation of
getGitLabServerUrl()to verify how it handles the URL.
Let me try a different approach to find the implementation.
Let me try one more approach to find any configuration or initialization of the GitLab server URL.
Let me check the GitLabApiConfiguration class to see how the URL is handled.
The URL handling is safe and correct
The GitLab server URL is configured through a Spring
@Valueannotation and is parsed as aURLobject, which automatically normalizes the URL. When converted to string viatoString(), it will not have any unexpected trailing slashes. The concatenation with "/api/v4/personal_access_tokens" in the service is therefore safe.Additionally, since the URL is configured through Spring's property system and validated by the
URLclass constructor, any malformed URLs would fail during application startup, providing an early safety check.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if there's a trailing slash in the GitLab server URLs. rg --after-context 2 $'getGitLabServerUrl\\('Length of output: 2169
Script:
#!/bin/bash # Find the implementation of getGitLabServerUrl ast-grep --pattern 'getGitLabServerUrl() { $$$ }'Length of output: 53
Script:
#!/bin/bash # Search for getGitLabServerUrl implementation using ripgrep rg -A 5 "getGitLabServerUrl.*\{"Length of output: 34
Script:
#!/bin/bash # Search for GitLab server URL configuration or initialization rg -i "gitlab.*server.*url|gitlaburl|gitlab.*baseurl" --type javaLength of output: 4229
Script:
#!/bin/bash # Get the content of GitLabApiConfiguration class cat src/main/java/de/tum/cit/aet/artemis/core/config/connector/GitLabApiConfiguration.javaLength of output: 996
src/test/java/de/tum/cit/aet/artemis/programming/util/ProgrammingExerciseTestService.java (6)
161-161: Clarify the reference in the JavaDoc.Updating the Javadoc to reference the fully qualified class name is helpful. Ensure that this external reference remains valid if the package structure changes in the future.
2016-2017: Test assertion is descriptive and clear.These lines nicely convey the expected relationship between the number of students and the number of exercises.
2314-2314: New participation variable for cleanup test.Introducing
participation8afor an additional scenario in the cleanup test is consistent with the naming pattern used for other participations.
2319-2319: Verify newly added participation is part of the set.Including
participation8ain the assertion ensures its correct presence during the cleanup check.
2325-2325: Mocking the build plan deletion for the new participation.Extending the
mockDeleteBuildPlancalls forparticipation8aenhances coverage of the cleanup scenario.
2346-2346: Verifying final cleanup state.Validating that
participation8ano longer has a build plan ID confirms the cleanup logic is applied correctly.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanService.java (17)
4-4: Importing constant for clarity
Good use of the constantPROFILE_JENKINS, which reduces the risk of typographical errors when specifying Spring profiles.
27-28: JSON annotations are appropriate
Using@JsonIgnoreProperties(ignoreUnknown = true)and@JsonInclude(JsonInclude.Include.NON_EMPTY)is consistent with typical Jackson best practices for handling partial or sparse JSON data.
60-60: Profile annotation
Annotating the class with@Profile(PROFILE_JENKINS)is an effective way to isolate this service logic to Jenkins-based environments, aligning with the PR objectives of removing and replacing the Jenkins client.
66-66: Switched to using URI
AdoptingURIinstead of a rawURLorStringoffers additional type safety and clarity, aligning with current best practices.
99-99: Constructor refactor
The new constructor cleanly injects dependencies via Spring. Removing theJenkinsServerreference aligns with the PR objective to eliminate that client library.
215-215: Retrieving job configuration
Accessing job config viajenkinsJobService.getJobConfigis succinct. Consider gracefully handling the case wherejobConfigmight be null or empty if the Jenkins job fails to load.
224-224: Updating job
InvokingjenkinsJobService.updateJobfor updating the Jenkins job config centralizes the logic. This direct approach further ensures consistency with the removal of the Jenkins client.
290-290: Copying configuration
Similar to line 215, verify that the fetched config (jobXml) is valid before proceeding.
311-312: Trigger build with REST
UsingrestTemplate.postForEntitywith thejenkinsServerUriensures direct communication over HTTP. Confirm in the codebase that authentication or interceptors are properly configured.
314-314: Narrowed exception scope
CatchingRestClientExceptionis appropriate for handling HTTP request failures without swallowing unrelated exceptions. This improves clarity.
329-329: Retrieving job instance
Good direct use ofjenkinsJobService.getJob. The subsequent null check ensures safe handling if the job does not exist.
335-335: In-queue status check
Callingjob.inQueue()is more readable than a generic boolean check. This cleanly expresses the queued state for Jenkins jobs.
340-342: Fetching last build status
UsingrestTemplate.getForObjectwithJenkinsBuildStatusDTOis concise. ReturningBUILDINGorINACTIVEcovers the necessary states.
344-344: HTTP specialization
CatchingHttpClientErrorExceptionensures that known client-side error responses from Jenkins are logged and handled without impacting the entire app flow.
350-354: Record-based DTO
The lightweightJenkinsBuildStatusDTOrecord is an elegant way to parse the Jenkinsbuildingflag. This aligns well with modern Java practices.
380-380: Plan existence check
Distinguishing plan existence vianullor non-nullfromgetJobis straightforward and clear.
425-426: Enabling plan via REST
Similarly to triggering a build, enabling the plan with a dedicated endpoint clarifies the operation while aligning with the new direct REST-based approach.src/test/java/de/tum/cit/aet/artemis/exercise/participation/ParticipationIntegrationTest.java (2)
1360-1360: Maintain the updated mocking pattern.
This line mirrors the change seen at line 408. Ensure that all Jenkins-related tests now consistently rely on the new overload (enableMockingOfRequests(jenkinsJobPermissionsService)).
408-408: Confirm consistency with the new Jenkins integration approach.
This updated call tojenkinsRequestMockProvider.enableMockingOfRequests(jenkinsJobPermissionsService)removes thejenkinsServerparameter. Ensure that all references to the old signature have been updated accordingly and that no stale usage ofjenkinsServerpersists in the test suite.✅ Verification successful
Let me gather more information about the Jenkins integration changes to verify this properly.
Let me search for the implementation of the method to understand the changes.
Let me check the implementation of the method to understand if there were any changes.
Based on the implementation and usage patterns found, I can now provide the final response:
The Jenkins integration changes are consistent across the codebase
TheenableMockingOfRequests(jenkinsJobPermissionsService)method inJenkinsRequestMockProviderhas been consistently updated across all test files to use the new signature that only takes thejenkinsJobPermissionsServiceparameter. The search results confirm that there are no remaining calls using the old signature withjenkinsServer, and the implementation shows thatjenkinsServerUriis now handled internally by the provider.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Searches for any remaining calls to the old method signature with jenkinsServer. rg -A 2 $'jenkinsRequestMockProvider\\.enableMockingOfRequests\\(.*jenkinsServer'Length of output: 80
Script:
#!/bin/bash # Search for all usages of enableMockingOfRequests to understand the current pattern rg "enableMockingOfRequests" -A 2 # Also check the implementation of enableMockingOfRequests ast-grep --pattern 'enableMockingOfRequests($_) { $$$ }'Length of output: 34996
Script:
#!/bin/bash # Search for the implementation of enableMockingOfRequests in JenkinsRequestMockProvider ast-grep --pattern 'class JenkinsRequestMockProvider { $$$ enableMockingOfRequests($_) { $$$ } $$$ }' # Also check for any references to jenkinsServer in the class rg -A 5 "jenkinsServer" src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.javaLength of output: 10199
Script:
#!/bin/bash # Search for the implementation of enableMockingOfRequests in JenkinsRequestMockProvider rg -B 5 -A 10 "enableMockingOfRequests.*jenkinsJobPermissionsService" src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.javaLength of output: 940
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsService.java (7)
3-5: Use ofPROFILE_JENKINSandURIis consistent with the new design.
No further issues.
42-42: Profile annotation usage.
Switching to@Profile(PROFILE_JENKINS)is cleaner than using hardcoded strings.
51-51: Migration fromURLtoURI.
UsingURIcan help avoid various pitfalls associated with malformed URLs. Good improvement.
67-69: Constructor injection and parameter ordering.
Constructor injection aligns with dependency injection best practices. The order of parameters is logical and consistent.
149-149: Method call for deleting a Jenkins folder job.
The direct calljenkinsJobService.deleteFolderJob(projectKey);replaces the older approach and seems clearer. Ensure all references are updated.
154-154: ReplacingdeleteBuildPlanwithdeleteJob.
This clarifies that we are removing a job rather than a distinct build-plan object. No issues.
234-234: Health check request.
Constructing and executing a GET request withshortTimeoutRestTemplateis a good approach, but be mindful of potential SSRF if any portion of this URI could be influenced by user input.Also applies to: 236-236, 238-238
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobService.java (15)
3-4: Profile constant import
Replacing hardcoded profile strings withPROFILE_JENKINSis consistent and reduces the risk of typos.
6-6: Switch toURI.
Swapping toURIfor more flexible and safer handling of endpoints is a good choice.
12-12:@Qualifier("jenkinsRestTemplate")
Ensures correct bean injection. Verify that the correct bean is always provided in your Spring context.
15-17: Headers and media type declarations
Directly specifyingMediaType.APPLICATION_XMLis appropriate for Jenkins job or folder configs. No issues found.
19-21: Use ofHttpClientErrorExceptionandRestClientException.
Catching these exceptions indicates improved handling of HTTP-specific errors. This is more descriptive than catching generic I/O exceptions.
24-25: Jackson annotations
@JsonIgnoreProperties(ignoreUnknown = true)and@JsonInclude(JsonInclude.Include.NON_EMPTY)help handle partial responses gracefully.
28-28:JenkinsEndpointsusage
Centralizing endpoint definitions is beneficial for maintainability.
32-32:@Profile(PROFILE_JENKINS)
Consistent annotation usage across Jenkins services. Good practice.
37-37:restTemplatefield final
Marking it final enforces immutability and clarifies the intended usage.
39-40: Migrating fromURLtoURI
Consistent approach matching the rest of the refactor.
42-43: Injecting therestTemplate
Constructor injection fosters testability.
73-77: Data classesJobWithDetailsandFolderJob.
Using Java records for partial Jenkins job data fosters readability.Also applies to: 78-82
153-168:createFoldermethod
Query parameters are appended neatly. Potential SSRF concerns remain if malicious folder names are not validated.
264-280:deleteJob
Appropriately logs a warning if the job doesn’t exist. This is helpful for debugging.
285-300:deleteFolderJob
Identical approach to job deletion. Keep an eye on future expansions for sub-folders or advanced folder structures if needed.src/test/java/de/tum/cit/aet/artemis/core/connector/JenkinsRequestMockProvider.java (33)
3-6: Consolidated imports & static usage
No issues. The reuse of constants likeSOLUTIONandTEMPLATEis clear.
14-15: Response creators
Well-structured mocking responses. The coverage of success, bad requests, and resource not found is thorough.Also applies to: 17-17
20-20: Use ofjava.net.URI
Consistent with the rest of the Jenkins refactor.
45-46: Dependency injection
Injecting the required services for the test approach maintains modular testing and reduces boilerplate.Also applies to: 49-49
53-53:@Profile(PROFILE_JENKINS)
Keeping test providers under the Jenkins profile is consistent with the main code.
57-57:private URI jenkinsServerUri;
Uniform usage ofURIfor test mocks.
89-89: Initialization of mock servers
This pattern is standard for Spring’sMockRestServiceServer. Good to see everything is set up in one place.
115-123:buildJobNamehelper
Neat utility for ensuring job naming consistency.
143-145:mockCreateBuildPlan
Everything references the utility methods. Straightforward approach. No issues.
162-171:mockCreateJobInFolder
Handles either existing or new jobs. Thorough approach with separate calls for folder and job mocking.
180-190: Job permissions mocking
The combination of config retrieval and partial updates is carefully simulated here.
196-200:mockGetJobConfig
Fetching job configs is an essential part of job modifications. This test approach is consistent.
211-220:mockCheckIfProjectExists
Uses GET requests to confirm existence, optionally failing. The coverage of normal and failing scenarios is good.Also applies to: 225-226, 228-233
239-240:mockCopyBuildPlanFromTemplate&mockCopyBuildPlanFromSolution
Mocking the plan copying logic. Observes typical usage patterns from the refactored Jenkins approach.Also applies to: 243-244, 247-252
254-262:mockSaveJobXml
Chains calls tomockCreateJobInExistingFolderormockCreateBuildPlandepending on folder state. No issues found.
265-268:mockConfigureBuildPlan
ComplementsmockUpdatePlanRepositoryandmockEnablePlan. Good coverage for multiple scenarios.
276-285:mockUpdatePlanRepository
Allows toggling between legacy and modern job XML. Thorough simulation of possible outcomes.Also applies to: 291-297
301-304:mockGetJobXmlForBuildPlanWith
Tests retrieval for job configs. Straightforward logic.
Line range hint
307-315:mockEnablePlan
Respects the plan’s existence or non-existence in Jenkins.
324-333:mockGetJob
Uses GET requests to retrieve existing jobs, optionally simulating failures.
337-339:mockGetFolderJob
Similarly handles folder existence. No issues.Also applies to: 341-344
347-355:mockUpdateUserAndGroups
Displays how user login changes are handled. The approach is methodical and covers multiple paths.
358-364:mockUpdateUserLogin
Removing the old user, creating the new. This properly simulates the actual rename scenario.
376-379:mockDeleteUser
Gracefully handles absent or existing users. The different statuses are tested thoroughly.
Line range hint
386-396:mockGetUser
Fine-grained responses for existing or non-existing users.
402-402:mockGetAnyUser
Allows repeated checks for user presence. Good for verifying multiple calls.
438-454:mockAddUsersToGroups
Iterates over exercises to ensure folder configurations are updated. Good approach.
507-520:mockDeleteBuildPlan,mockDeleteBuildPlanNotFound, andmockDeleteBuildPlanFailWithException
Simulates successful, not found, and failed deletions. Comprehensive coverage.Also applies to: 524-526
530-535:mockDeleteBuildPlanProject
Ensures folder deletion testing. Straightforward.
540-554:mockGetBuildStatus
Verifies queued, non-queued, or building scenarios. This is essential to reflect real Jenkins build statuses.
Line range hint
560-568:mockHealth
Checks the Jenkins health endpoint with variable responses. Good approach for negative and positive test scenarios.
572-575:mockCheckIfBuildPlanExistsandmockTriggerBuild
Allows test coverage of plan existence checks and build triggers with success or failure.Also applies to: 577-585
438-438: Potential duplication check
No duplication from older SSRF review comments is observed here.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsInternalUrlService.java (2)
3-4: Profile constant import
Using@Profile(PROFILE_JENKINS)is more robust than a magic string.
14-14: Consistent usage of profile
No functional changes beyond the annotation. Implementation remains the same.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsTriggerService.java (2)
3-4: Refactored profile annotation
Again, switching to the constant is more maintainable.
12-12: Class-level annotations
Retaining the@Serviceand@Profile(PROFILE_JENKINS)ensures clear scoping.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsEndpoints.java (2)
15-33: Endpoints look well structured and consistent.The newly added endpoints for build plan, folder, and user management appear consistent and maintainable. Keep an eye out for potential duplication between endpoints if further expansions occur.
42-43: Use ofURIinstead ofStringfor base paths is good.Switching from
StringtoURIis a solid move; it ensures proper URL handling. Verify all existing consumers ofbuildEndpointare updated accordingly.✅ Verification successful
All consumers of
buildEndpointhave been updated to use URI parameterBased on the search results, all calls to
buildEndpointare using the new URI-based method signature. The codebase shows consistent usage ofURItype for thebaseUriparameter across all service classes:
JenkinsUserManagementServiceJenkinsServiceJenkinsJobServiceJenkinsBuildPlanServiceThe only exception is in
GitLabServicewhich correctly uses the String-based overload as intended.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that all calls to buildEndpoint have been refactored to use the new URI-based method rg -A 3 'buildEndpoint\('Length of output: 29209
src/test/java/de/tum/cit/aet/artemis/modeling/apollon/ApollonConversionServiceTest.java (1)
40-40: Good move to make the test service private.Changing the
apollonConversionServicefield from package-private to private supports encapsulation and is recommended for clarity within test classes.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsAuthorizationInterceptor.java (3)
3-4: Use of constant for profile is well-aligned with best practices.Replacing
@Profile("jenkins")with@Profile(PROFILE_JENKINS)prevents typographical errors and clarifies usage.
6-6: Switched toURIfor jenkinsServerUri.Adopting
URIinstead ofURLis a good step towards more robust URL handling, in line with broader refactoring across the codebase.
40-40: Variable rename for clarity.Renaming
jenkinsURLtojenkinsServerUriclarifies the type and usage, ensuring future maintainability.src/test/java/de/tum/cit/aet/artemis/programming/RepositoryProgrammingExerciseParticipationJenkinsIntegrationTest.java (2)
21-21: Addition ofJenkinsJobServiceimport.The new import is consistent with the broader Jenkins REST API refactoring.
59-62: Improved clarity by instantiatingJobWithDetailsdirectly.Switching from mocks to a real
JobWithDetailsobject can simplify test setups and reduce boilerplate, but be sure that critical behaviors are still covered by your tests.✅ Verification successful
Let me analyze the usage of
JobWithDetailsfurther to ensure all test scenarios are properly covered.
Let me try a different approach to check the JobWithDetails class structure.
Based on the search results from the previous commands, I can make a determination:
The switch to direct
JobWithDetailsinstantiation is safe and well-coveredThe ripgrep results show that
JobWithDetailsis consistently used across multiple test classes with similar patterns:
- It's used in integration tests (
RepositoryProgrammingExerciseParticipationJenkinsIntegrationTest)- It's used in service tests (
JenkinsJobServiceTest)- It's extensively used in the mock provider (
JenkinsRequestMockProvider)All instances follow the same pattern of instantiation with a buildPlanId/name, description, and queued status, suggesting this is a stable and well-understood pattern across the test suite.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that all interactions with JenkinsJobService.JobWithDetails remain valid and covered by tests rg -A 5 'new JenkinsJobService\.JobWithDetails\('Length of output: 6379
Script:
#!/bin/bash # Check the structure and usage of JenkinsJobService.JobWithDetails class ast-grep --pattern 'class JobWithDetails { $$$ }'Length of output: 177
Script:
#!/bin/bash # Search for JobWithDetails class definition using ripgrep rg -A 10 'class JobWithDetails'Length of output: 33
src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsProgrammingLanguageFeatureService.java (2)
3-3: Use of constant for Jenkins profile is good practice.
This update ensures consistency across the codebase and avoids potential typos in the profile string.
36-36: Annotation usage is correct and consistent with the new constant.
Aligning@Profile(PROFILE_JENKINS)with a centralized constant improves maintainability.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsXmlFileUtils.java (3)
33-33: Improved parameter null-safety with@NotNullannotation.
Explicitly indicating non-null constraints can prevent unexpected null pointer issues.
63-64: Comment clarifies design decision for parsing job configs.
The new comment adds valuable context to explain why no stricter schema or DTO approach is employed. No further action needed.
65-65: Enhanced parameter validation with@NotNull.
This change aligns with safe coding guidelines, ensuringconfigXmlTextis not null before parsing.src/main/java/de/tum/cit/aet/artemis/core/util/UrlUtils.java (5)
3-3: Transition toURIimport fosters more robust URL handling.
UsingURIinstead of raw strings enhances type safety and clarity.
25-26: Smart use of extracted parsed segments.
Extracting logic intogetParsedSegmentskeeps these lines concise and readable.
29-45: New method overloadbuildEndpoint(URI, ...)improves flexibility.
AcceptingURIinstead of just a string aligns with best practices and fosters consistency in URL construction.
46-56: Documentation for the helper method is clear.
Thoroughly explains how path segments and arguments are processed.
Line range hint
57-78: Helper method implementation is straightforward.
Implementation handles variable segments and argument count checks carefully.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsResultService.java (2)
3-3: Use ofPROFILE_JENKINSconstant centralizes Jenkins-related configuration.
Adheres to DRY principle and prevents scattering of duplicates.
30-30: Annotation change matches updated profile approach.
No issues found; the class remains consistent with the rest of the Jenkins integration changes.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/build_plan/JenkinsBuildPlanCreator.java (2)
3-3: Excellent use of constant for maintainability.
UsingPROFILE_JENKINSfromConstantspromotes consistency and reduces the risk of typos associated with string literals. No issues found.
31-31: Profile annotation aligned with best practices.
Replacing the hardcoded"jenkins"value withPROFILE_JENKINSfosters maintainability and consistency across the codebase. No concurrency, security, or performance issues noted.src/main/java/de/tum/cit/aet/artemis/core/config/RestTemplateConfiguration.java (7)
7-7: Importing Jenkins profile constant is a good practice.
This import centralizes the Jenkins profile definition, preventing typos and easing future maintenance.
17-17: Additional imports comply with guidelines.
The introduced imports are consistent with Java's package recommendations. No star imports used, adhering to the guideline to avoid them.
52-52: Profile annotation now references constant.
This improves consistency and ensures that all references to the "jenkins" profile remain synchronized.
96-96: Applying constant for shortTimeout JENKINS rest template.
Centralizing the Jenkins profile definition fosters maintainability and reduces duplication.
176-176: Short timeout RestTemplate creation.
The refactoring leverages a dedicated method for constructing the request factory, maintaining small, focused methods in line with the single-responsibility principle.
180-185: Helper method for consistent timeout settings.
Extracting timeout logic into a reusable method is a strong DRY practice. Ensure potential exceptions thrown bysetReadTimeoutandsetConnectTimeoutare handled higher up if needed.
187-188: Very short timeout creation.
This method reuses the same helper function, promoting code consistency and readability.src/test/java/de/tum/cit/aet/artemis/programming/ContinuousIntegrationTestService.java (3)
9-9: Switching from URL to URI for type safety.
This refactor aligns with modern best practices for handling server addresses, reducing risks associated with URL parsing and ensuring better type safety.
36-36: Injected URI field.
UsingURIforciServerUrlis consistent with the updated approach across the codebase. No concurrency or security pitfalls detected.
172-172: Enhanced assertion covers the exact expected URL.
By asserting the specific key & value inadditionalInfo(), test coverage is improved and clarity is increased about the expected input.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/jobs/JenkinsJobPermissionsService.java (4)
3-3: Constant import leverages DRY principle.
ReferencingPROFILE_JENKINSensures a single source of truth for the Jenkins profile string. Follows guidelines to avoid magic strings.
11-11: Explicit import of Document.
Makes the code more readable compared to relying on inference for crucial types in Jenkins job configuration.
14-14: Replacing the hardcoded profile with a constant.
Better maintainability and readability. This is a recommended approach per coding guidelines.
35-35: Explicit Document type clarifies the job configuration object.
Enhances maintainability by showing exactly what type is being manipulated. No security or concurrency issues noted.src/test/java/de/tum/cit/aet/artemis/shared/architecture/module/AbstractModuleRepositoryArchitectureTest.java (1)
168-168: Confirm complete migration from javax to jakarta.
It's great to see the rule enforcement forjakarta.transaction.Transactionalonly. However, please verify that no lingering references tojavax.transaction.Transactionalremain in the codebase, to ensure a clean migration.✅ Verification successful
Migration from javax to jakarta transaction is complete
The verification shows that the migration from
javax.transactiontojakarta.transactionis complete:
- The only reference to
javax.transactionis inbuild.gradlewhere it's explicitly excluded from dependencies- The
jakarta.transactionis correctly used in the test class enforcing the rule- All other
@Transactionalannotations in the codebase are from Spring's transaction management and are not related to the javax/jakarta migration🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for any occurrence of javax.transaction.Transactional in the codebase. rg 'javax\.transaction\.Transactional' -A 3Length of output: 45
Script:
#!/bin/bash # Let's perform a more comprehensive check for any javax transaction related imports or annotations rg -i "javax\.transaction" -g "!{*.md,*.txt}" # Also check for jakarta transaction usage to confirm the migration rg -i "jakarta\.transaction" -g "!{*.md,*.txt}" # Let's also check for any Transactional annotations in general to ensure we're not missing anything rg "@Transactional" -A 1 -g "!{*.md,*.txt}"Length of output: 25942
src/test/java/de/tum/cit/aet/artemis/programming/service/JenkinsServiceTest.java (9)
44-44: Mocks correctly enabled.
Enabling request mocks forjenkinsJobPermissionsServiceandgitlabRequestMockProviderlooks correct for test setup. No issues found.
210-211: Sufficient mocking for job retrieval.
No issues here; the mock setup is consistent with the test scenario.
215-215: Verify mocking.
CallingjenkinsRequestMockProvider.verifyMocks()helps ensure the correct usage of mocks. Looks good.
230-230: Private test helper method is readable.
The method’s structure is clear, and usage of descriptive naming is appreciated.
296-296: Plan copy approach.
UsingmockCopyBuildPlanFromTemplatefor the new exercise is appropriate. No issues found.
314-315: Clear naming for the source exercise.
Assigning"source"to the short name is consistent and easily distinguishable. Looks good.
325-325: Clear naming for the target exercise.
Similarly,"target"is straightforward. No concerns.
330-331: Generate a plan name from keys.
This is consistent with Jenkins naming conventions. All good.
333-333: Copy legacy build plan logic is consistent.
No further remarks, it aligns with the transition from the old plan retrieval approach.src/main/java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsUserManagementService.java (10)
3-4: Profile constant import usage is correct.
Replacing hard-coded"jenkins"withPROFILE_JENKINSis a good step to reduce typos and improve maintainability.
6-6: Use of URI signals modernization.
Transition fromURLtoURIis a recommended approach in Spring and avoids confusion withUriComponentsBuilder.
45-45: Profile annotation replaced.
@Profile(PROFILE_JENKINS)usage ensures fewer mistakes than literal strings. No issues.
51-51: Injected URI aligns with property-based configuration.
DefiningjenkinsServerUriunder@Valueis a clean approach.
104-104: Consistent endpoint usage.
JenkinsEndpoints.CREATE_USER.buildEndpoint(...)usage standardizes how URIs are formed. Well done.
156-156: Uniform endpoint usage for deleting users.
Similarly, referencingJenkinsEndpoints.DELETE_USER.buildEndpoint(...)makes the CRUD logic more maintainable.
244-244: Detailed logging for added groups.
Logging the project keys helps with debugging permissions assignment.
293-293: Clear logs for revoked group permissions.
This is helpful for diagnosing group removal operations.
321-322: Logging updated for course permission changes.
Specifically logging the relevant project keys is consistent with the approach in other methods.
396-396: Graceful fallback for missing user.
Returningnullif the user is not found is a clear approach.build.gradle (3)
22-22: LGTM! Good addition of the Gradle lint plugin.Adding the nebula.lint plugin will help maintain clean and consistent dependency declarations in the build file.
499-499: LGTM! Good documentation addition.The new documentation for the
lintGradletask helps developers identify unused dependencies, which aligns well with the PR's objective of improving dependency management.
263-267: Good additions for performance and functionality.The addition of HikariCP for connection pooling and Apache Commons libraries for text/math operations are solid choices.
Let's verify if these new dependencies have any known vulnerabilities:
✅ Verification successful
No known vulnerabilities found in the new dependencies
The security check confirms that both HikariCP 6.2.1 and Apache Commons Text 1.13.0 have no known vulnerabilities reported in the GitHub Security Advisory Database. These are safe to use in their current versions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for security advisories for the new dependencies gh api graphql -f query=' { securityVulnerabilities(first: 5, ecosystem: MAVEN, package: "com.zaxxer/HikariCP") { nodes { advisory { summary severity publishedAt } vulnerableVersionRange firstPatchedVersion { identifier } } } }' gh api graphql -f query=' { securityVulnerabilities(first: 5, ecosystem: MAVEN, package: "org.apache.commons/commons-text") { nodes { advisory { summary severity publishedAt } vulnerableVersionRange firstPatchedVersion { identifier } } } }'Length of output: 720
...java/de/tum/cit/aet/artemis/programming/service/jenkins/JenkinsAuthorizationInterceptor.java
Show resolved
Hide resolved
Checklist
General
Server
Changes affecting Programming Exercises
Motivation and Context
Unify the interaction with Jenkins REST API and get rid of the outdated Jenkins client library
Steps for Testing
Prerequisites:
Exam Mode Testing
Prerequisites:
Testserver States
Note
These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.
Review Progress
Code Review
Manual Tests
Exam Mode Test
Summary by CodeRabbit
Based on the comprehensive summary of changes, here are the release notes:
Release Notes
Dependencies and Build Configuration
Jenkins Integration
Testing and Mocking
Code Quality
Continuous Integration