feat: Noir sync rework#12574
Conversation
|
We were pulling the noir version to use from the noir repository but now we don't have the noir repo downloaded during Edit: link isn't working nicely so I'm referring to the line We can fix this by pulling from the |
I think we need a patch which zeroes out the version reported by |
You mean that Perhaps instead of zeroing it out, it could change Although, if we cloned the code and they ran it, I'd be curious why the results are different than if they build it over there.
On a different note, the patch file would contain non-automated changes made by aztec devs, stuff we want to actually migrate back eventually. I'm trying to figure out how to distinguish them from the fixup so they don't get mixed up. |
Ah, obviously the patch file itself could do any number of changes 🤦 |
|
It looks like CI doesn't like my script Ah, now I see what |
d288f0c to
fe83b1a
Compare
1d7af38 to
4682ce5
Compare
|
Good with me. @charlielye thoughts on this PR? (though I'd hope not questioning the whole concept, at this point :)) |
|
I tried this out and ran into an issue with how it handles switching branches. This can be reproed by the steps.
This causes bootstrap.sh to skip checking out the noir repo and so the build fails with the error message below. |
|
@TomAFrench I can replicate what you got by doing the following:
I changed If there would be conflicts then a full |
Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>
Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com>
|
Ah sorry, fake news on my part. We should revert those changes. I misread the suggestion where |
|
|
||
| # Update the noir-repo before we hash its content, unless the command is exempt. | ||
| no_update=(clean make-patch bump-noir-repo-ref) | ||
| if [[ -z "$cmd" || ! ${no_update[*]} =~ "$cmd" ]]; then |
There was a problem hiding this comment.
Why not just hash the ref and the patch file? (tho we should still disable the cache if there's any local changes to noir repo, hmm)
There was a problem hiding this comment.
I didn't want to fundamentally change what the hashes work with: have we compiled and cached this code or not, including pending changes and local commits that may not be in the hash file.
| @@ -1,4 +1,4 @@ | |||
| # Create a pull request from current Noir master. | |||
| # Create a pull request from current Noir nightly. | |||
There was a problem hiding this comment.
I dont know if you guys still want a workflow to make PRs into noir with the patch, but otherwise we can delete the other side of the sync noir workflow
There was a problem hiding this comment.
I thought opening a PR could involve some mechanical steps, such as rebasing on the remote branch without the fixup and patch marker commit, which could benefit from automation, even if it's just manually triggered, but we should definitely disable any automation for now. I thought we can return to this question once we actually have a situation and understand better what's a nice way to do it. @TomAFrench ?
There was a problem hiding this comment.
Yeah, I'm fine with doing this manually in the short term and automating it later.
| echo "./yarn-project/constants/precommit.sh" >>$hooks_dir/pre-commit | ||
| chmod +x $hooks_dir/pre-commit | ||
| echo "(cd noir && ./postcheckout.sh $@)" >$hooks_dir/post-checkout | ||
| chmod +x $hooks_dir/post-checkout |
There was a problem hiding this comment.
Maybe we should do this right after checking out submodules? As this is basically "getting a submodule" our own way.
Also would mean going to the transpiler for the version above not needed
There was a problem hiding this comment.
This doesn't actually check out the noir-repo, it does not initialise it, it just checks whether it has commits that should be patched. (I just pushed a fix to make sure it works correctly if the repo doesn't exist yet).
The other difference I think is that if I put it after the update of submodules, it would print this message whenever the developer runs a build and there are commits in the noir-repo. I don't want that, because they might just be running builds on the same branch over and over; what I want is to warn them iff they switch away to a different aztec-packages branch, before they initiate a build on the new branch, which could end up checking out a different branch/tag/commit of noir-repo for them. Before they do so they should think about switching back to where they came from, create a patch there and commit it. If it's okay, then until they switch branches again they can work in peace.
Contains the changes from #12574 to replace the copy of the noir-repo with a `noir-repo-ref` file to point at the nightly version which we pull during the build. Updated `noir-repo-ref` in the PR to match the last merge sync PR #12624 Alternatively it could be set to include the commits from the open #12669 by setting it to [nightly-2025-03-14](https://github.com/noir-lang/noir/commits/nightly-2025-03-14) Added a patch to replicate the changes to honk test programs in #12266 Opened noir-lang/noir#7706 to migrate the patch back to Noir --------- Co-authored-by: Akosh Farkash <aakoshh@gmail.com> Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com> Co-authored-by: aakoshh <akosh@aztecprotocol.com>
Contains the changes from AztecProtocol/aztec-packages#12574 to replace the copy of the noir-repo with a `noir-repo-ref` file to point at the nightly version which we pull during the build. Updated `noir-repo-ref` in the PR to match the last merge sync PR AztecProtocol/aztec-packages#12624 Alternatively it could be set to include the commits from the open AztecProtocol/aztec-packages#12669 by setting it to [nightly-2025-03-14](https://github.com/noir-lang/noir/commits/nightly-2025-03-14) Added a patch to replicate the changes to honk test programs in AztecProtocol/aztec-packages#12266 Opened noir-lang/noir#7706 to migrate the patch back to Noir --------- Co-authored-by: Akosh Farkash <aakoshh@gmail.com> Co-authored-by: Tom French <15848336+TomAFrench@users.noreply.github.com> Co-authored-by: aakoshh <akosh@aztecprotocol.com>
Check out Noir during build
Changes the way we sync the code from Noir away from having a periodically synced copy of the codebase, to checking out the code during the build based on a tag/branch/commit indicated by a file or env var.
The following new files were added:
noir/noir-repo-refcontains the reference in Noir that should be checked outinitcommand does the initial checkout and theupdatecommand switches to new branchesnoir/bootstrap.shperforms aninitandupdatebefore every command exceptcleanTODO:
git amstops at them, and withgit am --allow-emptyit just failsnoir-repo. (Currently an error is returned bysync.shbut if we created a patch file, it should be committed on the aztec-packages branch we switched away from).\noir-repo-refto the next release.pull-noirworkflow:Rationale
Currently there is a two-way sync between Noir and aztec-packages, with automated workflows running daily to push changes between the
masterbranches by opening (or appending to already open) sync PRs. The two-way sync was required because for example frequent changes in thebbinterface were easier to update in this repo and pushed back to Noir, than to have to wait for a release cycle.The problem we frequently encounter with the sync from Noir is that some of the integration tests in aztec-packages break due to subtle changes in the compiler, which we don't know about until we open the sync PR. At that point we're looking at a potentially long list of changes (every commit on
mastersince the last sync), and it's not clear which one is the culprit. We bisect the build to find a failure, fix it in the PR, but this often just reveals the next bug to be fixed.This process can take days, and during that time the sync process has to be paused - if it runs it just makes the PR bigger, with potentially more bugs. Regardless of whether we pause it or let it append to the PR, no new features or fixes get merged into aztec-packages until all the bugs are squashed.
Instead what we wish to achieve here is that we can:
masteronto the release branch so that the good stuff can go in.Example
The following example shows:
noir-repoto a tag