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

Update macos and ubuntu ci to be more extensive #173

Merged
merged 12 commits into from
Dec 22, 2023
Merged

Update macos and ubuntu ci to be more extensive #173

merged 12 commits into from
Dec 22, 2023

Conversation

mcbarton
Copy link
Collaborator

@mcbarton mcbarton commented Dec 19, 2023

Added section that will run tests on arm osx once free tier github runner available (currently commented out)
Build cppyy and tests on macos as well as linux, and where CppInterOp uses clang-repl as well as cling
Use homebrew provided clang rather than apple provided clang
Test for both clang-repl 16 and 17 for both macos and linux
Update ubuntu runner to be consistent across all Ubuntu runners

Copy link

codecov bot commented Dec 19, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (cf18068) 72.75% compared to head (2d93347) 77.55%.

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #173      +/-   ##
==========================================
+ Coverage   72.75%   77.55%   +4.79%     
==========================================
  Files           8        8              
  Lines        2885     2887       +2     
==========================================
+ Hits         2099     2239     +140     
+ Misses        786      648     -138     
Files Coverage Δ
lib/Interpreter/CppInterOpInterpreter.h 92.77% <100.00%> (+17.77%) ⬆️

... and 5 files with indirect coverage changes

Files Coverage Δ
lib/Interpreter/CppInterOpInterpreter.h 92.77% <100.00%> (+17.77%) ⬆️

... and 5 files with indirect coverage changes

@mcbarton
Copy link
Collaborator Author

mcbarton commented Dec 19, 2023

Issues that have shown as a result of the CI running is
ubu22-gcc12-clang-repl-17 fails, but ubu22-gcc12-clang-repl-17-cppyy fails (not entirely sure why, and will look into)

cling based ci runs fails. Unsure why. Only noticed difference from quick glance is that previous run of ci was using cached llvm. This run built from scratch. Any details on cached cling and llvm-project it uses would be useful.

@alexander-penev @vgvassilev I thought from this readme that there was a smaller m1 github runner https://github.com/actions/runner-images/blob/main/images/macos/macos-13-arm64-Readme.md . Given it keeps waiting for runner then it may not exist. Based on this thread then the only github m1 runners may currently be the xl variants actions/runner-images#8439 which cost money. I can change it to this runner if the project is willing to bare the cost until there is a free one. Let me know what you want me to do

It's also worth noting that my ci update was to use macos version 13, but come January there are plans for a beta which uses macos version 14 (latest version). see actions/runner-images#7508

@mcbarton
Copy link
Collaborator Author

More details on the larger macos runners if you decide to proceed with that route for now https://docs.github.com/en/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners . I know from issue #138 that it wasn't expected to be necessary due to llvm caching.

@mcbarton
Copy link
Collaborator Author

By fixing the version of cling in CI to the latest version, rather than using the latest commit I have now been able to have the ci pass for cling based jobs. It is currently hardcoded, but it future the version can be chosen against the version of clang cling is being built alongside.

ubu22-gcc12-clang-repl-17 failing doesn't appear to have anything to do with the changes I have made for this PR.

Now this PR is just waiting on a decision as to what arm based macos runner should it be run on (i.e. the xlarge ones which currently cost money to run on, or wait and see if a free variant is made available)

@vgvassilev
Copy link
Contributor

The cache system requires one successful build of llvm and then the rest is built on top. Could we employ that to avoid the costs of M1?

@mcbarton
Copy link
Collaborator Author

The cache system requires one successful build of llvm and then the rest is built on top. Could we employ that to avoid the costs of M1?

I don't think you can completely avoid the costs of the M1, but you can certainly limit the costs, by using your cache (so run time minutes are low for most runs, and only high if cache needs updating), and have it only run the macos tests by manually activating them instead of automatically like currently. For example you only run it once you are satisfied that the ubuntu tests are all ok for a PR.

@mcbarton
Copy link
Collaborator Author

The only time I can think of that a new llvm cache would need creating for the M1 ci runs is when a new patch is added to the project, so that the ci can test with the new patch.

@mcbarton
Copy link
Collaborator Author

@vgvassilev I managed to find this message actions/runner-images#8439 (comment) which is relevant. Github plan to offer a free tier for M1 sometime next year (it says the date is to be decided, but they are still ramping up their hardware acquisition until about March 2024). My suggestion is I update this PR to have extensive tests for macos x86, which should catch any ci issues with macos builds. I would comment out the arm based jobs for now until the date for the free tier of m1 runners has been announced, and the correct runner key can be added. I'd update the commit message and PR name accordingly. What do you think?

…eing, until free m1 github runner tier available)
@mcbarton
Copy link
Collaborator Author

mcbarton commented Dec 21, 2023

@vgvassilev I managed to find this message actions/runner-images#8439 (comment) which is relevant. Github plan to offer a free tier for M1 sometime next year (it says the date is to be decided, but they are still ramping up their hardware acquisition until about March 2024). My suggestion is I update this PR to have extensive tests for macos x86, which should catch any ci issues with macos builds. I would comment out the arm based jobs for now until the date for the free tier of m1 runners has been announced, and the correct runner key can be added. I'd update the commit message and PR name accordingly. What do you think?

Implementing this suggestion has raised the following issues with ci in this PR

Once I determine how to solve the xcode related issue I will push a commit solving these issues

@mcbarton mcbarton changed the title Update CI to run on arm based macos system + run extra tests in CI Update macos and ubuntu ci to be more extensive Dec 21, 2023
@mcbarton
Copy link
Collaborator Author

mcbarton commented Dec 21, 2023

@alexander-penev I consider this PR ready for review. The issue which stops osx-x86-clang-clang-repl-17-cppyy and osx-x86-clang-clang-repl-16-cppyy passing although appears to be to do with the xcode on the runner, it doesn't appear to be due to this from further inspection, since it passes when CppInterOp uses cling instead of clang-repl. I plan to remove the line
sudo xcode-select -s /Applications/Xcode_15.1.app/Contents/Developer
from the ci once any issues you raise are fixed, since this xcode isn't available yet despite being in the readme.

Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

@mcbarton
Copy link
Collaborator Author

@vgvassilev thanks for the suggestion of what was stopping the clang repl cppyy ci jobs from passing, and @alexander-penev for implementing this fix. Do the commits just need to be squashed now, or is this PR in need of further review?

- name: ubu22-gcc9-clang-repl-16
os: ubuntu-22.04
os: ubuntu-latest
Copy link
Collaborator

Choose a reason for hiding this comment

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

If not explicitly required ubuntu-latest, it is better to keep the specific version. Makes the matrix more stable for github changes.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

At the time the ci had both ubuntu-22.04 and ubuntu-latest . I didn't know which one to pick. I should have realised from the name. I've now made this change.

#Block commented out until free tier for m1
#exists (expected sometime 2024) and key for os
#can be replaced
#- name: osx-arm-clang-clang-repl-17
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe in the name it is better to put arm64 instead of just arm.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've now made this change, as well as change osx to osx13 to make it clear its running on macos version 13.

#FIXME: Need latest version of cling not hardcoded.
git clone https://github.com/root-project/cling.git
cd ./cling
git checkout tags/v1.0
Copy link
Collaborator

@alexander-penev alexander-penev Dec 22, 2023

Choose a reason for hiding this comment

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

Instead of a hardcoded version of cling, we can add in the build matrix a new parameter for example cling-version:
- name: ubu22-gcc9-clang13-cling
os: ubuntu-22.04
compiler: gcc-9
clang-runtime: '13'
cling: On
cling-version: '1.0'
...

And then this is written as:
git checkout tags/v${{ matrix.cling-version }}

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done this change.

Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

cd cppyy-backend
mkdir -p $CPPINTEROP_DIR/lib build && cd build
# Install CppInterOp
(cd $CPPINTEROP_BUILD_DIR && cmake --build . --target install --parallel $(nproc --all))
# Build and Install cppyy-backend
cmake -DCppInterOp_DIR=$CPPINTEROP_DIR ..
cmake --build . --parallel $(nproc --all)
OS=$(uname -s)
if [[ "$OS" == "Darwin" ]]; then
cp libcppyy-backend.dylib $CPPINTEROP_DIR/lib/
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please indent the command by 2 spaces.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done

OS=$(uname -s)
if [[ "$OS" == "Darwin" ]]; then
cp libcppyy-backend.dylib $CPPINTEROP_DIR/lib/
else
cp libcppyy-backend.so $CPPINTEROP_DIR/lib/
Copy link
Collaborator

Choose a reason for hiding this comment

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

Please indent the command by 2 spaces.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done

Copy link
Contributor

clang-tidy review says "All clean, LGTM! 👍"

@mcbarton
Copy link
Collaborator Author

@alexander-penev I just tried squashing the commits on my local machine, but it seems to remove you as a contributor when I do so. Can you tell me how I do this while keeping all the contributors in the squashed commit?

@alexander-penev alexander-penev merged commit 7fc1874 into compiler-research:main Dec 22, 2023
16 checks passed
@kgantchev
Copy link

. I would comment out the arm based jobs for now until the date for the free tier of m1 runners has been announced, and the correct runner key can be added. I'd update the commit message and PR name accordingly. What do you think?

Might I make a suggestion here? Feel free to use FlyCI's M1 and M2 runners. Our runners are on average 2x faster and 2x cheaper than GitHub's AND we have a free tier for OSS projects (see below).

Install Instructrions

Easily replace your M1 runners:

jobs:
 ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m1
   steps:
   - name: 👀 Checkout repo
     uses: actions/checkout@v4

Or try the M2 runners:

jobs:
  ci:
-    runs-on: macos-latest
+    runs-on: flyci-macos-large-latest-m2
    steps:
      - name: 👀 Checkout repo
        uses: actions/checkout@v4

Pricing

Processor vCPU RAM (GB) Storage Label Price on FlyCI Price on GitHub
M1 4 7 28 GB flyci-macos-large-latest-m1 $0.06 -
M1 8 14 28 GB flyci-macos-xlarge-latest-m1 $0.12 $0.16
M2 4 7 28 GB flyci-macos-large-latest-m2 $0.08 -
M2 8 14 28 GB flyci-macos-xlarge-latest-m2 $0.16 -

500 mins/month Free for Public Repos

If your repo is public, then FlyCI offers 500 mins/month of free M1 runner usage with the flyci-macos-large-latest-m1 runner.

Best Regards,
Kiril Gantchev
CEO and co-founder of FlyCI

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.

4 participants