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 some Rust smoketesting CI for barretenberg_wrapper #14

Merged
merged 6 commits into from
Jan 12, 2023

Conversation

phated
Copy link

@phated phated commented Jan 11, 2023

This adds some CI for the barretenberg_wrapper crate. I wanted to get this added so we are more comfortable with changes such as my #9 PR and #8 (which we'll want to rebase on this). I believe ARM support is on the GitHub Action roadmap, so we'll be able to expand this matrix in the future.

I also needed to fix some rust formatting and clippy stuff in separate commits.

I'll also have some comments inline.

Depends upon #13

Comment on lines 44 to 48
# TODO: Enable when tests work
# - name: Run cargo test
# working-directory: "./barretenberg_wrapper"
# run: |
# cargo +${{ matrix.toolchain }} test
Copy link
Author

Choose a reason for hiding this comment

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

On linux, running cargo test fails with a ton of linker errors. I'm not sure why.

On Mac, the tests pedersen tests fail with (what looks like) an ordering problem.

I'd love some help getting the tests working in this project.

Copy link
Author

Choose a reason for hiding this comment

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

I've updated the tests to match aztec_backend as per @vezenovm's suggestions and re-enabled the test step. I'm guessing we'll still have issues with linking on Linux though.

Copy link
Author

Choose a reason for hiding this comment

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

The linux tests were failing because rust picks up gcc as the linker on ubuntu. I've added a config file to override that as per rust-lang/rust#71515 (comment)

Copy link
Author

@phated phated Jan 11, 2023

Choose a reason for hiding this comment

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

Also, it seems by specifying this inside of barretenberg_wrapper, it'll apply when used as a dependency as per the Hierarchical Structure documentation: https://doc.rust-lang.org/cargo/reference/config.html#hierarchical-structure

@phated phated force-pushed the bb/rust-smoketests branch from 1159376 to b1959d3 Compare January 11, 2023 20:08
@phated phated requested a review from jfecher January 11, 2023 20:08
@phated phated force-pushed the bb/rust-smoketests branch 2 times, most recently from 10ab90b to 4070246 Compare January 11, 2023 21:35
@@ -0,0 +1,2 @@
[target.x86_64-unknown-linux-gnu]
Copy link
Author

@phated phated Jan 11, 2023

Choose a reason for hiding this comment

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

I believe we'll want to add something similar for aarch64-unknown-linux-gnu in PR #8

@phated phated force-pushed the bb/rust-smoketests branch from 4070246 to 08a95c5 Compare January 11, 2023 22:00
@TomAFrench
Copy link
Member

process didn't exit successfully: /home/runner/work/aztec-connect/aztec-connect/barretenberg_wrapper/target/debug/deps/barretenberg_wrapper-c6045f1b11456fbf (signal: 4, SIGILL: illegal instruction)

This looks like the same error message I'm getting when trying to build barretenberg locally. There's something in the test files which is borked (everything builds fine if you delete all the tests).

@phated
Copy link
Author

phated commented Jan 11, 2023

@TomAFrench It looks flakey, as they pass most of the time. I updated a couple tests that weren't updated but maybe there are others that need to be updated. I'll ask @vezenovm

@@ -0,0 +1,93 @@
name: Rust

on: [push, pull_request]
Copy link
Member

@TomAFrench TomAFrench Jan 11, 2023

Choose a reason for hiding this comment

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

Suggested change
on: [push, pull_request]
on:
push:
branches: 'kw/noir-dsl'
pull_request:
branches: '*'

This currently runs CI twice on PRs.

Copy link
Author

@phated phated Jan 11, 2023

Choose a reason for hiding this comment

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

Running the PR twice is actually good because a push runs with the branch as it's own base and pull_request runs with the upstream as the base.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure I follow on this. When you say "with the upstream as the base" do you mean "as if the PR were rebased on top of the branch being merged into"? I haven't heard anything about push and pull_request treating the same commit differently.

Copy link
Author

Choose a reason for hiding this comment

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

As per https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request

Note that GITHUB_SHA for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, use github.event.pull_request.head.sha instead.

Thus, the checkout action running on something triggered by pull_request will checkout a merge between the upstream and the PR and test it. And push just checks out to the commit that is pushed.

Copy link
Member

Choose a reason for hiding this comment

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

Hmm, interesting. I didn't know that GH did that temporary merge for pull_request.

Personally I generally try to avoid merging branches into a base branch which is ahead of it (e.g. through first merging back into the PR branch) to check this explicitly rather than relying on GH.

@TomAFrench
Copy link
Member

It looks flakey, as they pass most of the time.

Unfortunately it's 100% of the time for me which prevents me from building anything noir-related.

@phated
Copy link
Author

phated commented Jan 11, 2023

Unfortunately it's 100% of the time for me which prevents me from building anything noir-related.

I'm confused, why are the tests being built if you are building Noir itself? This issue is only showing up when the tests are run in this repository.

There was a separate Illegal instruction failure within the googletest stuff, but that should be disabled since 2630271 - Please note that always_configure is set to false so you actually need to cargo clean to ensure CMake configuration is being re-done.

@jfecher
Copy link

jfecher commented Jan 11, 2023

I can confirm that I also get the Illegal Instruction error in the google tests 100% of the time when building barretenberg (on my other machine - linux x86_64).

@TomAFrench
Copy link
Member

TomAFrench commented Jan 11, 2023

Aha, I've just been running bootstrap.sh in the barrentenberg directory directly as it seemed sensible to get that building and then work my way up. This means that we don't end up turning off the TESTING flag like we do in build.rs.

I've added that manually to ./bootstrap.sh and I can build properly now.

@phated
Copy link
Author

phated commented Jan 11, 2023

Oh, I wouldn't trust the bootstrap.sh file. There's a build.rs file in barretenberg_wrapper that builds barretenberg and configures rust to use it.

I suppose we can add the -DTESTING=OFF flag though.

@TomAFrench
Copy link
Member

TomAFrench commented Jan 11, 2023

I'm confused, why are the tests being built if you are building Noir itself? This issue is only showing up when the tests are run in this repository.

There was a separate Illegal instruction failure within the googletest stuff, but that should be disabled since 2630271

Yeah, I think the ./bootstrap.sh stuff is a bit of a red herring now.

When building nargo I get the errors fixed in #13 and 2630271. These are fixed now and nargo just needs to have dependencies updated. Not knowing this, I came here to try and hunt down the issue and once Barretenberg starts throwing the same error as nargo did, it's natural to try and troubleshoot there.

@phated
Copy link
Author

phated commented Jan 11, 2023

nargo just needs to have dependencies updated

Yep! I'm working on getting everything updated so nargo builds. I just started on Monday and nargo wouldn't build on my Mac with everything fresh. So, of course, I've been on a mission to make sure it works! Just waiting on a few PRs across various repos.

@TomAFrench
Copy link
Member

Thanks, I apprecate it! I just tested with your PR on aztec_backend and it allowed me to build nargo again after quite some time.

@phated phated requested a review from vezenovm January 11, 2023 23:24
Copy link

@jfecher jfecher left a comment

Choose a reason for hiding this comment

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

LGTM 👍

@phated phated merged commit ae1d7cd into kw/noir-dsl Jan 12, 2023
@phated phated deleted the bb/rust-smoketests branch January 12, 2023 15:08
ax0 pushed a commit to ax0/aztec-connect that referenced this pull request Jan 12, 2023
* Cargo format

* Clippy fixes

* Update tests to match tests in aztec_backend

* Add cargo config to set clang as linker when target is x86_64-unknown-linux-gnu
ax0 pushed a commit to ax0/aztec-connect that referenced this pull request Jan 12, 2023
* Cargo format

* Clippy fixes

* Update tests to match tests in aztec_backend

* Add cargo config to set clang as linker when target is x86_64-unknown-linux-gnu
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