-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Upload native build statistics #39784
Upload native build statistics #39784
Conversation
.github/import_stats.sh
Outdated
# update timing info if present | ||
if [ -e "$ts" ]; then | ||
curl -s -w '\n' -H "Content-Type: application/json" -H "token: $TOKEN" \ | ||
-X PUT --data "@$ts" "$URL/$stat_id" > /dev/null | ||
fi |
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.
This shouldn't be needed as the build time is part of the latest build-output.json
s. It would be better to feed the quarkus version as an update with the new /update-runner-info
endpoint.
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.
👍 I am waiting for the new RunnerInfo to get deployed to collector.foci.life first (see Karm/collector#23 (comment))
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.
OK. Either way the PUT
call for timing info is redundant these days and should not be included.
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.
@zakkak If you enable GHA on your Q fork, you can switch the endpoint to stage and run it of your own G account, right?
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.
Yes, I will do this, and also enable the job to run on forks, it currently is supposed to run only on the main repo on the main
branch.
dddcfe0
to
70ddd16
Compare
Note that you could use an approach similar to: quarkus/.github/workflows/develocity-publish-build-scans.yml Lines 33 to 39 in 824234e
to also add it as a step summary (which allows to visualize things right away instead of downloading the file) |
8fd0d3b
to
9368eb7
Compare
That would be a json file per integration-test, wouldn't it be too much noise in the report? What do you think would make more sense to be shown in the report? |
6c87de6
to
ec781e2
Compare
This comment has been minimized.
This comment has been minimized.
724d42d
to
3c4133b
Compare
This comment has been minimized.
This comment has been minimized.
ad6c821
to
42d9ba9
Compare
This comment has been minimized.
This comment has been minimized.
This is blocked by Karm/collector#27 |
This comment has been minimized.
This comment has been minimized.
ae8263e
to
d41c47c
Compare
d41c47c
to
c23eb7f
Compare
This comment has been minimized.
This comment has been minimized.
959576e
to
5fa39fb
Compare
661ee75
to
61ae566
Compare
This comment has been minimized.
This comment has been minimized.
61ae566
to
874d587
Compare
This comment has been minimized.
This comment has been minimized.
874d587
to
61380b8
Compare
This seems to work (tested with Main IT in https://github.com/zakkak/quarkus/actions/runs/9254781855) @Karm please have a look. |
{ | ||
"test_version": "$GITHUB_REF_NAME", | ||
"quarkus_version": "$GITHUB_SHA", | ||
"jdk_version": "$(java -version 2>&1 | head -n 2 | tail -n 1)", | ||
"operating_system": "$RUNNER_OS", | ||
"architecture": "$RUNNER_ARCH", | ||
"memory_size_bytes": "$(awk '/MemTotal/ {print $2 * 1024}' /proc/meminfo)", | ||
"memory_available_bytes": "$(awk '/MemAvailable/ {print $2 * 1024}' /proc/meminfo)", | ||
"description": "Quarkus CI github runner on $GITHUB_REF_NAME branch/tag", | ||
"triggered_by": "Quarkus CI" | ||
} |
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.
Runner info extracted here might be different from the actual GHA runner that ran the native integration test, no? Should we not collect the info where the native tests ran?
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.
The only thing I expect to actually change is memory_available_bytes
as AFAIK all free-tier github runners have the same resources. So I am not sure if it's worth creating a new runner for each IT-category (since each category runs on its own runner). No strong opinions though.
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.
So maybe we should keep the runner info empty (or some value indicating the values are somewhat meaningless), so as to avoid concluding something from the runner info. That's the only worry. The only info relevant for quarkus should be the test_version
and quarkus_version
, right?
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.
So maybe we should keep the runner info empty (or some value indicating the values are somewhat meaningless), so as to avoid concluding something from the runner info.
That makes sense
The only info relevant for quarkus should be the test_version and quarkus_version, right?
Right, that should be enough for #40076
Done.
This comment has been minimized.
This comment has been minimized.
61380b8
to
2512ca5
Compare
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.
Looks OK to me.
This comment has been minimized.
This comment has been minimized.
Since Quarkus CI already runs the native tests quite often with a fixed Mandrel version, we can gather these data and increase our insight regarding Quarkus changes that affects image build time statistics.
2512ca5
to
d470e57
Compare
Status for workflow
|
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.
Seems sane to me and consistent with this use case: https://github.com/Karm/mandrel-integration-tests/blob/bfb82325b3d3a4838a0e5567d77097ad03a22b36/aux_scripts/run_qts_host.sh
@zakkak The only nitpick would be some perhaps needlessly missing attributes from runner info, e.g.
"operating_system": "$(uname -o)",
"architecture": "$(uname -m)",
"memory_size_bytes": $(awk '/MemTotal/ {print $2 * 1024}' /proc/meminfo),
"memory_available_bytes": $(awk '/MemAvailable/ {print $2 * 1024}' /proc/meminfo),
Yes, we had that in place but as suggested by @jerboaa in #39784 (comment) I agree it is better we remove them given that they don't come from the actual runner (the runner uploading the data is different than the runner that did the actual runners). If you think we really need this info I can modify it (in a follow up PR) to use a runner-info per IT-category and report the actual numbers. |
Follow up to quarkusio#39784 Resolves: ``` jq: error: Could not open file /home/runner/work/quarkus/quarkus/./integration-tests/simple: No such file or directory ``` by treating each line returned by `find` as a single path instead of further breaking it down by space.
Follow up to quarkusio#39784 Resolves: ``` jq: error: Could not open file /home/runner/work/quarkus/quarkus/./integration-tests/simple: No such file or directory ``` by treating each line returned by `find` as a single path instead of further breaking it down by space.
Follow up to quarkusio#39784 Resolves: ``` jq: error: Could not open file /home/runner/work/quarkus/quarkus/./integration-tests/simple: No such file or directory ``` by treating each line returned by `find` as a single path instead of further breaking it down by space.
Since Quarkus CI already runs the native tests quite often with a fixed
Mandrel version, we can gather these data and increase our insight
regarding Quarkus changes that affects image build time statistics.