Development: Automatically update build queues in local continuous integration
#7836
Conversation
WalkthroughThe recent update reflects an enhancement in the local continuous integration (CI) build queue system within a Java-based project. A new WebSocket service was integrated for real-time communication, and listeners were added to handle item and entry events in the build queue. The web interface was also updated to remove redundant elements, and frontend components now include WebSocket subscription logic for dynamic updates. Changes
Poem
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? TipsChat with CodeRabbit Bot (
|
github-actions
bot
added
server
…queue-representation # Conflicts: # src/main/java/de/tum/in/www1/artemis/service/connectors/localci/LocalCISharedBuildJobQueueService.java
mateusmm01
temporarily deployed
to
artemis-test6.artemis.cit.tum.de
GitHub Actions
Inactive
mateusmm01
temporarily deployed
to
artemis-test6.artemis.cit.tum.de
GitHub Actions
Inactive
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files ignored due to filter (2)
- src/main/webapp/i18n/de/buildQueue.json
- src/main/webapp/i18n/en/buildQueue.json
Files selected for processing (4)
- src/main/java/de/tum/in/www1/artemis/service/connectors/localci/LocalCISharedBuildJobQueueService.java (5 hunks)
- src/main/java/de/tum/in/www1/artemis/web/websocket/localci/LocalCIBuildQueueWebsocketService.java (1 hunks)
- src/main/webapp/app/localci/build-queue/build-queue.component.html (1 hunks)
- src/main/webapp/app/localci/build-queue/build-queue.component.ts (1 hunks)
Files skipped from review due to trivial changes (1)
- src/main/webapp/app/localci/build-queue/build-queue.component.html
Additional comments: 6
src/main/java/de/tum/in/www1/artemis/web/websocket/localci/LocalCIBuildQueueWebsocketService.java (1)
- 14-55: The class
LocalCIBuildQueueWebsocketServiceis well-structured with clear responsibilities for sending WebSocket messages related to build queues. It adheres to Spring's standard practices with appropriate use of@Serviceand@Profileannotations, and dependency injection forWebsocketMessagingService.src/main/webapp/app/localci/build-queue/build-queue.component.ts (1)
- 12-74: The updates to
BuildQueueComponentinclude proper handling of WebSocket subscriptions and unsubscriptions, following Angular's best practices for lifecycle hooks. ThecourseChannelsarray is a good approach to track and manage multiple WebSocket channels.src/main/java/de/tum/in/www1/artemis/service/connectors/localci/LocalCISharedBuildJobQueueService.java (4)
- 77-89: > Note: This review was outside the patches, so it was mapped to the patch with the greatest overlap. Original lines [80-101]
The addition of
LocalCIBuildQueueWebsocketServiceand the implementation of Hazelcast listeners inLocalCISharedBuildJobQueueServiceare correctly done. The listeners are set up to respond to changes in the build job queue and processing jobs, and they use the WebSocket service to communicate these changes to clients.
409-426: The
QueuedBuildJobItemListenerclass correctly handles the addition and removal of build jobs from the queue. It updates the WebSocket clients with the current state of the queue, ensuring real-time data synchronization.429-445: The
ProcessingBuildJobItemListenerclass ensures that clients are updated with the current running build jobs. It responds to the addition and removal of jobs in the processing map, maintaining the real-time status of the build process.448-459: The
BuildAgentListenerclass updates clients with the current build agent information upon changes. This keeps the clients informed about the available build agents and their status.
|
github-actions
bot
added
the
deployment-error
mateusmm01
added
deploy:artemis-test3
and removed
deployment-error
mateusmm01
temporarily deployed
to
artemis-test3.artemis.cit.tum.de
GitHub Actions
Inactive
MaximilianJG
temporarily deployed
to
artemis-test2.artemis.cit.tum.de
GitHub Actions
Inactive
armanhabibiTUM
temporarily deployed
to
artemis-test6.artemis.cit.tum.de
GitHub Actions
Inactive
…queue-representation
MaximilianJG
temporarily deployed
to
artemis-test2.artemis.cit.tum.de
GitHub Actions
Inactive
…queue-representation
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (1)
- src/main/java/de/tum/in/www1/artemis/service/connectors/localci/LocalCISharedBuildJobQueueService.java (5 hunks)
Additional comments: 7
src/main/java/de/tum/in/www1/artemis/service/connectors/localci/LocalCISharedBuildJobQueueService.java (7)
22-23: The addition of
EntryAddedListenerandEntryRemovedListenerimports aligns with the implementation of new listener classes for WebSocket functionality.36-36: The import of
LocalCIBuildQueueWebsocketServiceis necessary for the WebSocket communication introduced in this PR.80-86: The constructor has been correctly updated to include
LocalCIBuildQueueWebsocketServicefor WebSocket communication. Ensure that all instances ofLocalCISharedBuildJobQueueServiceare updated to pass this new dependency.Verification successful
The search for instances where
LocalCISharedBuildJobQueueServiceis instantiated did not yield any results. This could mean that the service is not directly instantiated using thenewkeyword, which is common for Spring-managed beans. Instead, it is likely that the service is injected by Spring's dependency injection mechanism.Given this, it's not possible to verify through the provided script whether all instances of
LocalCISharedBuildJobQueueServicehave been updated to include the new constructor parameter. A different approach is needed to ensure that the Spring context is correctly configured to inject the new dependency whereLocalCISharedBuildJobQueueServiceis used.To verify that the Spring context is correctly configured to handle the updated constructor, we should look for the Spring configuration files or annotations that define the beans.
The output from the script indicates that
LocalCISharedBuildJobQueueServiceis annotated with@Serviceand@Profile("localci"), which are Spring annotations used to define a bean within the Spring application context. The@Serviceannotation marks the class as a service provider, and the@Profileannotation suggests that this service is only active when the "localci" profile is used.Since the service is managed by Spring, we do not expect direct instantiations with the
newkeyword. Instead, Spring will automatically handle the injection of dependencies into other beans that requireLocalCISharedBuildJobQueueService.Given this information, it is not necessary to look for updates to the constructor calls in the codebase, as Spring's dependency injection container will take care of providing the required
LocalCIBuildQueueWebsocketServicebean toLocalCISharedBuildJobQueueServicewhen it is instantiated.Therefore, the review comment is addressed correctly under the assumption that the Spring context is properly configured to autowire the new dependency. However, without checking the configuration of
LocalCIBuildQueueWebsocketServicebean and whereLocalCISharedBuildJobQueueServiceis injected, we cannot fully verify that the new dependency is handled correctly everywhere it is needed.To ensure that
LocalCIBuildQueueWebsocketServiceis correctly configured as a Spring bean and injected whereverLocalCISharedBuildJobQueueServiceis used, we would need to check the configuration ofLocalCIBuildQueueWebsocketServiceand the injection points ofLocalCISharedBuildJobQueueService.
The output confirms that
LocalCIBuildQueueWebsocketServiceis also annotated with@Serviceand@Profile("localci"), indicating that it is a Spring-managed bean that will be instantiated and injected by Spring's dependency injection mechanism when the "localci" profile is active.Additionally, the output shows the
LocalCISharedBuildJobQueueServiceconstructor with the@Autowiredannotation, which is the point where Spring injects the required dependencies. Since the constructor includesLocalCIBuildQueueWebsocketServiceas a parameter, this confirms that Spring is expected to provide an instance ofLocalCIBuildQueueWebsocketServicewhen creatingLocalCISharedBuildJobQueueService.There is no additional output showing other injection points for
LocalCISharedBuildJobQueueService, which suggests that the constructor is the primary (or only) point where dependencies are injected. This is typical for Spring services, where the constructor injection is used to provide all necessary dependencies.Based on the information provided by the script output, it appears that the Spring configuration is set up correctly to handle the new dependency on
LocalCIBuildQueueWebsocketServicewithinLocalCISharedBuildJobQueueService. Therefore, the review comment regarding the constructor update and the need to ensure that all instances are updated to pass the new dependency is verified as correct within the context of Spring's dependency injection.* 98-100: Listeners for queued and processing build jobs, as well as build agents, have been registered correctly to enable WebSocket updates.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that all instances of LocalCISharedBuildJobQueueService are updated with the new constructor parameter. rg "new LocalCISharedBuildJobQueueService\("Length of output: 46
Script:
#!/bin/bash # Search for Spring configuration files or annotations related to LocalCISharedBuildJobQueueService rg "@Bean|@Component|@Service|@Repository" -A 3 | rg "LocalCISharedBuildJobQueueService"Length of output: 579
Script:
#!/bin/bash # Check the configuration of LocalCIBuildQueueWebsocketService bean rg "@Bean|@Component|@Service|@Repository" -A 3 | rg "LocalCIBuildQueueWebsocketService" # Check for injection points of LocalCISharedBuildJobQueueService rg "@Autowired" -A 3 | rg "LocalCISharedBuildJobQueueService"Length of output: 1439
409-427: The
QueuedBuildJobItemListenerclass correctly handles WebSocket messages for build job queue events. It sends updates when items are added or removed from the queue.429-445: The
ProcessingBuildJobItemListenerclass correctly handles WebSocket messages for processing job events. It sends updates when items are added or removed from the processing jobs map.448-459: The
BuildAgentListenerclass correctly handles WebSocket messages for build agent events. It sends updates when build agents are added or removed.
krusche
changed the title
Enhancement: Enable websockets for build job queue representation in local continuous integrationDevelopment: Automatically update build queues in local continuous integration
krusche
deleted the
enhancement/localci/websockets-for-build-queue-representation
branch
Checklist
General
Server
Client
Motivation and Context
Currently, we use REST Calls to update the build job queue table. For this, the user needs to manually refresh the content.
Description
By using WebSockets, the table now updates on its own when new build jobs get queued or start running. For this, a new
LocalCIBuildQueueWebsocketServicewas created that sends the BuildQueue over different channels. TheBuildQueueComponenthad to be changed accordingly to subscribe to these channels and receive the content.Steps for Testing
Prerequisites:
Either do this with other reviewers or with multiple tabs/browsers open
As Admin:
Navigate to Server Administration > Build Queue
As Instructor:
For all courses: Navigate to Course Management > Course xy > Build Queue
As Students of those courses:
Submit some Programming Exercises multiple times from all courses.
As an Instructor, you should now automatically see some Build Jobs appearing in the Build Queue. These should, however, only be for this specific course.
As an Admin, you should see all possible Build Jobs from all courses appearing automatically.
Testserver States
Note
These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Review Progress
Performance Review
Code Review
Manual Tests
Test Coverage
Screenshots
Server Administration > Build Queue:
Navigate to Course Management > Course xy > Build Queue:
Summary by CodeRabbit
Summary by CodeRabbit
New Features
Enhancements
Refactor
Documentation