Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrated code lifecycle: Add duration in build queue view #8608

Conversation

BBesrour
Copy link
Member

@BBesrour BBesrour commented May 16, 2024

Checklist

General

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.
  • Following the theming guidelines, I specified colors only in the theming variable files and checked that the changes look consistent in both the light and the dark theme.
  • I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
  • I documented the TypeScript code using JSDoc style.
  • I added multiple screenshots/screencasts of my UI changes.
  • I translated all newly inserted strings into English and German.

Motivation and Context

This helps improve the time needed for a quick overview of the running build agents and possible problems.

Admins need a way to view the buildjob duration quickly and to be warned when a job lasts longer than 4 min (default timeout time for jobs in the server)

Steps for Testing

Prerequisites:

  • 1 Admin
  • 1 Student
  • 1 Programming Exercise
  1. Create a programming exercise and change the build script to the following
set -e

maven () {
  echo '⚙️ executing maven'
  sleep 200
  mvn clean test
}

main () {
  maven
}

main "${@}"
  1. As student, participate in the exercise and submit
  2. As admin, open the buildqueue view and check the Build Duration. Make sure that its being updated and that the value is correct using the Build Start Date
  3. Row should be highlighted when Build duration > 4 mins (This might not happen since the default timeout is 4min on the server. You can test this locally and increase the timeout)

Testserver States

Note

These badges show the state of the test servers.
Green = Currently available, Red = Currently locked






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

Screenshots

(Changed the time to trigger the highlight to 10s for demo)
image

@BBesrour BBesrour added client Pull requests that update TypeScript code. (Added Automatically!) small component:integrated code lifecycle labels May 16, 2024
@BBesrour BBesrour self-assigned this May 16, 2024
@BBesrour BBesrour requested a review from a team as a code owner May 16, 2024 14:12
Copy link

coderabbitai bot commented May 16, 2024

Walkthrough

The recent updates to the build queue component enhance the user interface by adding conditional styling and formatting for build durations. Additionally, the component now dynamically updates build job durations every second, ensuring real-time accuracy. These changes improve the visibility and tracking of build processes, providing a more responsive and informative user experience.

Changes

File Change Summary
src/.../build-queue/build-queue.component.html Updated the template to include conditional styling and formatting for build durations. Added new column definitions for build duration and submission date with enhanced display features.
src/.../build-queue/build-queue.component.ts Introduced an interval property to periodically update build job durations. Implemented the updateBuildJobDuration() method to handle duration calculations and updates. Set up an interval to refresh durations every second and clear it upon component destruction.

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
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.

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 a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @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[bot]
coderabbitai bot previously approved these changes May 16, 2024
coderabbitai[bot]
coderabbitai bot previously approved these changes May 16, 2024
coderabbitai[bot]
coderabbitai bot previously approved these changes May 16, 2024
}
}
// This is necessary to update the view when the build job duration is updated
this.runningBuildJobs = JSON.parse(JSON.stringify(this.runningBuildJobs));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the proper way would be to trigger the change detection.
Or at least only create a new array instead of parsing it: this.runningBuildJobs = [...this.runningBuildJobs];

Copy link
Member Author

@BBesrour BBesrour May 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These unfortunately didn't work when I tried them

  • ref.detectChanges() doesn't work due to how ngx-datatable is implemented
  • this.runningBuildJobs = [...this.runningBuildJobs]; didn't work too (although they say that it should work in their docs)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The spread operator ('...') is a shallow copy method, which means it copies the elements of the array but not the nested objects themselves, they remain referenced to the original objects.
The JSON.parse(...) is a deep copying method and creates entirely new and independent objects.
I did not go into detail on BuildJobs -Class, but this could explain why only the parsing works correctly for your runningBuildJobs array

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we already use eslint could we not just use the deep copy method of that library?
Also I'm not completely sure but could setting it to an empty array first and then re-setting it work?

coderabbitai[bot]
coderabbitai bot previously approved these changes May 16, 2024
@BBesrour BBesrour changed the title Integrated code lifecycle: add buildjob duration in buildqueue view Integrated code lifecycle: Add buildjob duration in buildqueue view May 16, 2024
Copy link

⚠️ Unable to deploy to test servers ⚠️

Testserver "artemis-test3.artemis.cit.tum.de" is already in use by PR #8613.

Copy link

⚠️ Unable to deploy to test servers ⚠️

Testserver "artemis-test3.artemis.cit.tum.de" is already in use by PR #8613.

@github-actions github-actions bot added the deployment-error Added by deployment workflows if an error occured label May 17, 2024
Copy link
Contributor

@Jan-Thurner Jan-Thurner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally in a testing session as TS3 is currently in use. Works as expected.

Copy link
Contributor

@az108 az108 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tested in a testing session locally due to TS3 being currently in use. Works as intended

Copy link
Contributor

@rstief rstief left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code LGTM overall 👍 Two small notes but those do not need to be addressed right now

}
}
// This is necessary to update the view when the build job duration is updated
this.runningBuildJobs = JSON.parse(JSON.stringify(this.runningBuildJobs));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we already use eslint could we not just use the deep copy method of that library?
Also I'm not completely sure but could setting it to an empty array first and then re-setting it work?

@krusche krusche changed the title Integrated code lifecycle: Add buildjob duration in buildqueue view Integrated code lifecycle: Add duration in build queue view May 18, 2024
@krusche krusche merged commit d9143b9 into develop May 18, 2024
30 of 34 checks passed
@krusche krusche deleted the feature/integrated-code-lifecycle/add-buildjob-duration-in-buildqueue-view branch May 18, 2024 07:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
client Pull requests that update TypeScript code. (Added Automatically!) component:integrated code lifecycle deployment-error Added by deployment workflows if an error occured ready for review ready to merge small tests
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

8 participants