-
Notifications
You must be signed in to change notification settings - Fork 338
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
enable additional platforms in CI #1121
base: riscv
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,6 @@ | ||
# Build Spike and run a couple of debug tests. | ||
|
||
name: Test OpenOCD against 2 spike configurations | ||
name: Test OpenOCD against 4 spike configurations | ||
|
||
env: | ||
SPIKE_REPO: https://github.com/riscv-software-src/riscv-isa-sim.git | ||
|
@@ -115,7 +115,8 @@ jobs: | |
--gcc /opt/riscv/toolchain/bin/riscv-none-elf-gcc \ | ||
--gdb /opt/riscv/toolchain/bin/riscv-none-elf-gdb \ | ||
--sim_cmd /opt/riscv/spike/bin/spike \ | ||
--server_cmd $GITHUB_WORKSPACE/src/openocd | ||
--remotelogfile-enable \ | ||
--server_cmd "$GITHUB_WORKSPACE/src/openocd -d3" | ||
|
||
- name: Run Spike64-2 Tests | ||
if: success() || steps.spike32-tests.conclusion == 'failure' | ||
|
@@ -125,7 +126,30 @@ jobs: | |
--gcc /opt/riscv/toolchain/bin/riscv-none-elf-gcc \ | ||
--gdb /opt/riscv/toolchain/bin/riscv-none-elf-gdb \ | ||
--sim_cmd /opt/riscv/spike/bin/spike \ | ||
--server_cmd $GITHUB_WORKSPACE/src/openocd | ||
--remotelogfile-enable \ | ||
--server_cmd "$GITHUB_WORKSPACE/src/openocd -d3" | ||
|
||
- name: Run Spike64-2-hwthread Tests | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now that the number of of tests has increased, it may be worth to split them to multiple jobs that would then run in parallel, leading to overall shorter test time. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes, this is definitely a way to go. Will investigate how to do this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It looks to me that the current job can be split to multiple parallel jobs quite easily using strategy-matrix feature of Github Actions. Here is a concrete example: https://github.com/HonzaMat/PyOpenocdClient/blob/main/.github/workflows/integration_tests.yml#L7 |
||
if: success() || steps.spike32-tests.conclusion == 'failure' | ||
run: | | ||
cd riscv-tests/debug | ||
./gdbserver.py targets/RISC-V/spike64-2-hwthread.py --print-failures \ | ||
--gcc /opt/riscv/toolchain/bin/riscv-none-elf-gcc \ | ||
--gdb /opt/riscv/toolchain/bin/riscv-none-elf-gdb \ | ||
--sim_cmd /opt/riscv/spike/bin/spike \ | ||
--remotelogfile-enable \ | ||
--server_cmd "$GITHUB_WORKSPACE/src/openocd -d3" | ||
|
||
- name: Run Spike32-2-hwthread Tests | ||
if: success() || steps.spike32-tests.conclusion == 'failure' | ||
run: | | ||
cd riscv-tests/debug | ||
./gdbserver.py targets/RISC-V/spike32-2-hwthread.py --print-failures \ | ||
--gcc /opt/riscv/toolchain/bin/riscv-none-elf-gcc \ | ||
--gdb /opt/riscv/toolchain/bin/riscv-none-elf-gdb \ | ||
--sim_cmd /opt/riscv/spike/bin/spike \ | ||
--remotelogfile-enable \ | ||
--server_cmd "$GITHUB_WORKSPACE/src/openocd -d3" | ||
JanMatCodasip marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
- name: Archive test logs | ||
# Proceed even if there was a failed test | ||
|
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 would prefer not to add
-d3
here. The reason is:d3
could change OpenOCD behavior (there are many cases ofif (debug_level < 3) return;
).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.
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.
Exactly. After this change there will be no testing of OpenOCD without
-d3
.Anyway, I don't have a strong opinion on this so I'll approve the change regardless.
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.
@JanMatCodasip , @MarekVCodasip do you have an opinion on the matter? The concern raised by @en-sc is valid.
I'm inclined to extend testing even more by enabling both variants: "-d3" is enabled and "-d3" is omitted. Tests may be run a little bit slower now, however I think that we are better safe than sorry
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.
Please, don't. This is pre-commit testing. I believe it's better to run such tests at least in post-commit.
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.
There will always remain a little risk that adding
-d3
will change behavior -- IMO very small but still present.My recommendation would be to:
if (debug_level < XYZ ) return;
(in a separate merge request).-d3
slightly more but don't feel strongly).riscv
branch.riscv
branch (schedule options in Github Actions).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.
@en-sc
I don't believe we should reduce amount when creating a commit in open source. We already had few regressions that could be detected by a more rigorous testing. This commit is a direct response on one of such regression. I don't mind waiting 40 minutes instead of 20 to get testing results. I don't think this is a bit problem.
@JanMatCodasip
The thing is it is not that simple and may require a significant effort. Things are getting more complicated since the decision to use such approach was promoted in upstream several months ago. So unless the policy regarding such condition is changed in upstream - the issue shall persist. But we definitely should revise existing codebase regarding the matter.
My pick would be -d3 too since usually this logging level allows to debug test.
I'll investigate this . Thanks for the idea.
As for messing up with different logging levels, I believe this may be an over complication. However, your suggestion regarding splitting test into multiple job may help with this one.