-
Notifications
You must be signed in to change notification settings - Fork 136
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
Ci busy no more #143
Ci busy no more #143
Conversation
CI MessageYour results will arrive shortly |
Exiting stuff, will review soon! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In response to PR creation
CI Message
Run successful see results:
✔️ PR submitted to develop branch
✔️ Speed tester performance check passed
✔️ Linter passed
[Results from nimbnode30]
- Median TX pps for Speed Tester: 38624205
- Performance rating - 110.35% (compared to 35000000 average)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a fan of the main CI pipeline call both adding events to the queue and running all of them in a while loop, would be better if a dedicated thread was specifically waiting for those events to be added to the list, and then processing those.
Also the name ci_list
isn't very descriptive, we should do better. Something like ci_job_list
or ci_requests_list
?
Overall cool stuff though looking forward to not waiting 10 minutes for ci requests 👍
ci/webhook-receiver.py
Outdated
duplicate_req = False | ||
busy_msg = "Duplicate request already waiting, ignoring message" | ||
with queue_lock: | ||
# make sure we don't bypass thread safety |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this comment be above one line? Before you grab the queue_lock
ci/webhook-receiver.py
Outdated
run_manager(request_ctx) | ||
while len(ci_list) > 0: | ||
# new requests were made since our last call, run them in order | ||
run_manager(ci_list.pop(0)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though I think this is safe (pop is atomic right?) the design isn't very elegant. Would it be possible for us to have a different thread poll the queue and run things when items appear there?
@onvm test thread |
@onvm test me again |
@onvm testing again |
CI MessageYour results will arrive shortly |
ci/webhook-receiver.py
Outdated
run_manager(ci_request_list.pop(0)) | ||
else: | ||
# no requests, sleep | ||
time.sleep(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Figured we could just sleep for a second, but not sure how long is best
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might want a sleeping queue sort of implementation in the future, but good enough for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean?
@onvm authorized stick in queue |
@onvm test please run |
Discussing these in slack |
@onvm test |
1 similar comment
@onvm test |
@onvm test 1 |
New message here |
3 similar comments
New message here |
New message here |
New message here |
@onvm first one |
CI MessageYour results will arrive shortly |
@onvm run me |
@onvm test |
onvmstats "commited" the changes because on nn44, cronjob for stats is running |
CI MessageError: ERROR: Failed to copy ONVM files to nimbnode17 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commented on the event flag, lmk what you think
|
||
def add_request(request_ctx): | ||
ci_request_list.append(request_ctx) | ||
if not request_event.isSet(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just set request_event.set()
and then do equest_event.clear()
in the request_handler?
manager_running = False | ||
if not ci_request_list: | ||
# list empty, go to sleep until signaled | ||
request_event.wait() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
request_event.wait()
request_event.clear()
I liked that idea, makes it look cleaner in |
onvmstats is now sentient and pushing commits? I'm impressed with our development program. |
CI MessageError: ERROR: Failed to copy ONVM files to nimbnode17 |
2 similar comments
CI MessageError: ERROR: Failed to copy ONVM files to nimbnode17 |
CI MessageError: ERROR: Failed to copy ONVM files to nimbnode17 |
@onvm do your thing |
CI MessageYour results will arrive shortly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@onvm do your thing
CI Message
Run successful see results:
✔️ PR submitted to develop branch
✔️ Pktgen performance check passed
✔️ Speed Test performance check passed
✔️ Linter passed
[Results from nimbnode17]
-
Median TX pps for Pktgen: 6325632
-
Performance rating - 105.43% (compared to 6000000 average)
-
Median TX pps for Speed Tester: 38346945
-
Performance rating - 109.56% (compared to 35000000 average)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes from previous review implemented, approving
A huge improvement to testing pull requests throughout the day!
Summary:
Previously, CI would not run a request if another was already running. This is a bug annoyance (especially for @koolzz ) when trying to merge things and get the 'go ahead' from CI. Now, CI will send a message that if we are busy, it will run right after the last CI. This only happens if a duplicate request is not already there. For example, while CI is busy, we make a 2 requests in another PR, only one of them will be put in the list.
Usage:
Regular with CI comment arguments
Merging notes:
TODO before merging :
Test Plan:
Review:
@koolzz again please lmk if anything doesn't work