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

Add support for 32bit CI build #782

Merged
merged 1 commit into from
Feb 28, 2024

Conversation

Krishna-13-cyber
Copy link
Contributor

Addresses #748

Copy link

codecov bot commented Feb 22, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.71%. Comparing base (8d52a36) to head (52040e8).
Report is 3 commits behind head on master.

Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #782   +/-   ##
=======================================
  Coverage   94.71%   94.71%           
=======================================
  Files          49       49           
  Lines        7342     7342           
=======================================
  Hits         6954     6954           
  Misses        388      388           

@vgvassilev
Copy link
Owner

Does that work for PRs? I don’t see a build.

@Krishna-13-cyber
Copy link
Contributor Author

Krishna-13-cyber commented Feb 22, 2024

Does that work for PRs? I don’t see a build.

Not then, I have enabled it now.

@@ -0,0 +1,118 @@
---
name: 'Platforms'
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
name: 'Platforms'
name: 'Arch'

- name: "Compile library"
run: |
mkdir build && cd build
cmake -DLLVM_DIR=/usr/lib/ -DCMAKE_BUILD_TYPE=DEBUG -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
cmake -DLLVM_DIR=/usr/lib/ -DCMAKE_BUILD_TYPE=DEBUG -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad
cmake -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad

- name: "Compile library"
run: |
mkdir build && cd build
cmake -DLLVM_DIR=/usr/lib/ -DCMAKE_BUILD_TYPE=DEBUG -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
cmake -DLLVM_DIR=/usr/lib/ -DCMAKE_BUILD_TYPE=DEBUG -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad
cmake -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad

- name: "Compile library"
run: |
mkdir build && cd build
cmake -DLLVM_DIR=/usr/lib/ -DCMAKE_BUILD_TYPE=DEBUG -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
cmake -DLLVM_DIR=/usr/lib/ -DCMAKE_BUILD_TYPE=DEBUG -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad
cmake -DLLVM_EXTERNAL_LIT="$(which lit)" ../../clad

Can we extract the step "Compile library" into one place as it seems to repeat across builds. The same for the other common steps. Maybe this could help?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry for the delayed response. Yes, I will look into this and patch it asap.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The patch has been updated but the workflow report says path not found, its not able to fetch this patch vgvassilev/clad/.github/workflows/called.yml@master.
My test-workflow works fine with the same https://github.com/Krishna-13-cyber/clad/actions/runs/8045618661

Copy link
Owner

Choose a reason for hiding this comment

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

Can you take a look how the clad main workflow is organized, we want something similar for this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, will do this.
Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi, I have updated with respect to clad convention adhering to matrix strategy.
Thanks!

@vgvassilev
Copy link
Owner

Nice! Now we need to figure out how to suppress the test failures. For this PR maybe it would be fine if we allow failures on armv7 and x86.

architecture:
strategy:
matrix:
target: [x86, armv7, aarch64]
Copy link
Owner

Choose a reason for hiding this comment

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

Looks like armv7 and aarch64 are considerable slower. Can we disable them?

Copy link
Contributor Author

@Krishna-13-cyber Krishna-13-cyber Feb 27, 2024

Choose a reason for hiding this comment

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

Yes, they are slower.
We had an intention to target multiple architectures right to get hold of failures/bugs so why should we disable them (due to time constraints).
Can we try any other workaround to fit in those(slower ones) as well?

@Krishna-13-cyber
Copy link
Contributor Author

Nice! Now we need to figure out how to suppress the test failures. For this PR maybe it would be fine if we allow failures on armv7 and x86.

Yes, we can solve the failures in a seperate PR.

@vgvassilev
Copy link
Owner

Nice! Now we need to figure out how to suppress the test failures. For this PR maybe it would be fine if we allow failures on armv7 and x86.

Yes, we can solve the failures in a seperate PR.

Looks like this won't work. Maybe in this PR we should add to each failing test: XFAIL: target={{(i686|i386).*}}. Can you try this and then we can drop the non-functional continue-on-error thing.

@Krishna-13-cyber
Copy link
Contributor Author

Nice! Now we need to figure out how to suppress the test failures. For this PR maybe it would be fine if we allow failures on armv7 and x86.

Yes, we can solve the failures in a seperate PR.

Looks like this won't work. Maybe in this PR we should add to each failing test: XFAIL: target={{(i686|i386).*}}. Can you try this and then we can drop the non-functional continue-on-error thing.

I added this continue-on-error for all the parallel jobs to run independently as without this thing other jobs abort due to any failure on any of the jobs present.
Yes, I will try adding this XFAIL: target={{(i686|i386).*}} to failing tests.

@Krishna-13-cyber
Copy link
Contributor Author

Looks like this won't work. Maybe in this PR we should add to each failing test: XFAIL: target={{(i686|i386).*}}. Can you try this and then we can drop the non-functional continue-on-error thing.

The failing tests get suppressed with XFAIL:* and not this XFAIL: target={{(i686|i386).*}}.
Should I use this?

@vgvassilev
Copy link
Owner

Looks like this won't work. Maybe in this PR we should add to each failing test: XFAIL: target={{(i686|i386).*}}. Can you try this and then we can drop the non-functional continue-on-error thing.

The failing tests get suppressed with XFAIL:* and not this XFAIL: target={{(i686|i386).*}}. Should I use this?

No, that will suppress even working tests.

@vgvassilev
Copy link
Owner

target={{(i686|i386).*}}

@Krishna-13-cyber, you need // XFAIL: target={{i586.*}}

Copy link
Owner

@vgvassilev vgvassilev left a comment

Choose a reason for hiding this comment

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

Awesome! LGTM!

@vgvassilev vgvassilev merged commit a200944 into vgvassilev:master Feb 28, 2024
81 checks passed
@Krishna-13-cyber
Copy link
Contributor Author

Awesome! LGTM!

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants