Integrated code lifecycle: Fix flickers in build queue

[BBesrour]

Checklist

General

• This is a small issue that I tested locally and was confirmed by another developer on a test server.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Client

• Important: I implemented the changes with a very good performance, prevented too many (unnecessary) REST calls and made sure the UI is responsive, even with large data.
• I strictly followed the client coding and design guidelines.
• I documented the TypeScript code using JSDoc style.

Motivation and Context

There is a small issue when build jobs are added/removed from the queue that caused it to flicker which made it hard to keep track of the table.

Steps for Testing

Prerequisites:

• 1 instructor or admin
• 1 programming exercise

1. Open the build queue (if logged in as instructor, you can find it under course management > build queue in the top right)
2. In another tab, spam the build queue by submitting repeatedly
3. Keep an eye on the build queue and make sure that it's not flickering and working correctly. Also make sure that the sort is working

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

Performance Review

• I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Summary by CodeRabbit

• New Features

  • Improved build queue component to provide more accurate job duration tracking.

• Bug Fixes

  • Fixed an issue where job durations were not properly calculated in the build queue.

• Tests

  • Updated unit tests to reflect changes in how build job durations are calculated.

[coderabbitai]

Walkthrough

The recent changes to the BuildQueueComponent class involve updating the updateBuildJobDuration method to accept a list of build jobs as a parameter, compute their durations, and return the updated list. This alteration necessitates adjusting how this method is invoked within the ngOnInit() function, enhancing the component's approach to handling build job duration calculations.

Changes

File	Change Summary
src/.../build-queue.component.ts	Modified updateBuildJobDuration method to take buildJobs: BuildJob[] as a parameter and return the updated list
src/.../build-queue.component.spec.ts	Adjusted method call in ngOnInit to pass component.runningBuildJobs to updateBuildJobDuration

---

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?

Share

• X
• Mastodon
• Reddit
• LinkedIn

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

Actionable comments posted: 3

[coderabbitai]

Actionable comments posted: 1

Outside diff range comments (4)

src/main/webapp/app/localci/build-queue/build-queue.component.ts (4)

Line range hint 423-423: Specify a more appropriate type instead of any.

The open method uses any for the content parameter. Using any disables many type checking rules and should be avoided. Please specify a more appropriate type.

---

Line range hint 31-32: Remove unnecessary type annotations for clarity and conciseness.

The type annotations on status and buildAgentAddress are inferred from their initial values and can be omitted.

-    status?: string = undefined;
-    buildAgentAddress?: string = undefined;
+    status = undefined;
+    buildAgentAddress = undefined;

---

Line range hint 163-163: Avoid assignments within expressions to enhance code clarity.

Using assignments within expressions can be confusing and should be avoided. Consider refactoring these to separate statements.

Also applies to: 298-298

---

Line range hint 313-324: Remove unnecessary else clause for cleaner code.

The else clause in filterDateChanged is unnecessary because the previous branches break early. Removing it can simplify the code structure.

[kaancayli]

Tested during testing session on TS3. Works as described. Code LGTM 👍

[DominikRemo]

Tested in testing session on ts3. LGTM

[EneaGore]

Tested in testing session. lgtm

[SimonEntholzer]

Worked fine during testing session 👍

[coolchock]

tested in testing sessions, LGTM

[JohannesStoehr]

We also have a pipe specifically for this purpose, called artemisTimeAgo. You might think about using this instead of your custom solution