Skip to content

Commit 5b89cff

Browse files
jtriley2pjtriley2p
authored
Initial commit
0 parents  commit 5b89cff

19 files changed

+3449
-0
lines changed

‎.github/NIGHTLY_CANARY_DIED.md‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
---
2+
title: "Tests fail on latest Nargo nightly release"
3+
---
4+
5+
The tests on this Noir project have started failing when using the latest nightly release of the Noir compiler. This likely means that there have been breaking changes for which this project needs to be updated to take into account.
6+
7+
Check the [{{env.WORKFLOW_NAME}}]({{env.WORKFLOW_URL}}) workflow for details.

‎.github/workflows/benchmark.yml‎

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
name: Benchmarks
2+
3+
on:
4+
push:
5+
branches:
6+
- master
7+
pull_request:
8+
9+
jobs:
10+
test:
11+
name: Benchmark library
12+
runs-on: ubuntu-latest
13+
steps:
14+
- name: Checkout sources
15+
uses: actions/checkout@v4
16+
17+
- name: Install Nargo
18+
uses: noir-lang/[email protected]
19+
with:
20+
toolchain: 0.36.0
21+
22+
- name: Install bb
23+
run: |
24+
npm install -g bbup
25+
bbup -nv 0.36.0
26+
27+
- name: Build Noir benchmark programs
28+
run: nargo export
29+
30+
- name: Generate gates report
31+
run: ./scripts/build-gates-report.sh
32+
env:
33+
BACKEND: /home/runner/.bb/bb
34+
35+
- name: Compare gates reports
36+
id: gates_diff
37+
uses: noir-lang/noir-gates-diff@7e4ddaa91c69380f15ccba514eac17bc7432a8cc
38+
with:
39+
report: gates_report.json
40+
summaryQuantile: 0.9 # only display the 10% most significant circuit size diffs in the summary (defaults to 20%)
41+
42+
- name: Add gates diff to sticky comment
43+
if: github.event_name == 'pull_request' || github.event_name == 'pull_request_target'
44+
uses: marocchino/sticky-pull-request-comment@v2
45+
with:
46+
# delete the comment in case changes no longer impact circuit sizes
47+
delete: ${{ !steps.gates_diff.outputs.markdown }}
48+
message: ${{ steps.gates_diff.outputs.markdown }}

‎.github/workflows/nightly-canary.yml‎

Lines changed: 40 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,40 @@
1+
name: Noir Nightly Canary
2+
3+
on:
4+
schedule:
5+
# Run a check at 9 AM UTC
6+
- cron: "0 9 * * *"
7+
8+
env:
9+
CARGO_TERM_COLOR: always
10+
11+
permissions:
12+
issues: write
13+
14+
jobs:
15+
test:
16+
name: Test on Nargo Nightly
17+
runs-on: ubuntu-latest
18+
steps:
19+
- name: Checkout sources
20+
uses: actions/checkout@v4
21+
22+
- name: Install Nargo
23+
uses: noir-lang/[email protected]
24+
with:
25+
toolchain: nightly
26+
27+
- name: Run Noir tests
28+
run: nargo test
29+
30+
- name: Alert on dead links
31+
uses: JasonEtco/create-an-issue@v2
32+
if: ${{ failure() }}
33+
env:
34+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
35+
WORKFLOW_NAME: ${{ github.workflow }}
36+
WORKFLOW_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}
37+
with:
38+
update_existing: true
39+
filename: .github/NIGHTLY_CANARY_DIED.md
40+

‎.github/workflows/pull-request-title.yml‎

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,30 @@
1+
name: Pull Request
2+
3+
on:
4+
merge_group:
5+
pull_request_target:
6+
types:
7+
- opened
8+
- reopened
9+
- edited
10+
- synchronize
11+
12+
permissions:
13+
pull-requests: read
14+
15+
jobs:
16+
conventional-title:
17+
name: Validate PR title is Conventional Commit
18+
runs-on: ubuntu-latest
19+
steps:
20+
- name: Check title
21+
if: github.event_name == 'pull_request_target'
22+
uses: amannn/action-semantic-pull-request@v5
23+
env:
24+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
25+
with:
26+
types: |
27+
fix
28+
feat
29+
chore
30+

‎.github/workflows/release.yml‎

Lines changed: 21 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,21 @@
1+
name: Release
2+
3+
on:
4+
push:
5+
branches:
6+
- master
7+
8+
jobs:
9+
release-please:
10+
name: Create Release
11+
outputs:
12+
release-pr: ${{ steps.release.outputs.pr }}
13+
tag-name: ${{ steps.release.outputs.tag_name }}
14+
runs-on: ubuntu-latest
15+
steps:
16+
- name: Run release-please
17+
id: release
18+
uses: google-github-actions/release-please-action@v3
19+
with:
20+
token: ${{ secrets.GITHUB_TOKEN }}
21+
command: manifest

‎.github/workflows/test.yml‎

Lines changed: 115 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,115 @@
1+
name: Noir tests
2+
3+
on:
4+
push:
5+
branches:
6+
- master
7+
pull_request:
8+
9+
env:
10+
CARGO_TERM_COLOR: always
11+
MINIMUM_NOIR_VERSION: v0.36.0
12+
13+
jobs:
14+
noir-version-list:
15+
name: Query supported Noir versions
16+
runs-on: ubuntu-latest
17+
outputs:
18+
noir_versions: ${{ steps.get_versions.outputs.versions }}
19+
20+
steps:
21+
- name: Checkout sources
22+
id: get_versions
23+
run: |
24+
# gh returns the Noir releases in reverse chronological order so we keep all releases published after the minimum supported version.
25+
VERSIONS=$(gh release list -R noir-lang/noir --exclude-pre-releases --json tagName -q 'map(.tagName) | index(env.MINIMUM_NOIR_VERSION) as $index | if $index then .[0:$index+1] else [env.MINIMUM_NOIR_VERSION] end')
26+
echo "versions=$VERSIONS"
27+
echo "versions=$VERSIONS" >> $GITHUB_OUTPUT
28+
env:
29+
GH_TOKEN: ${{ github.token }}
30+
31+
test:
32+
needs: [noir-version-list]
33+
name: Test on Nargo ${{matrix.toolchain}}
34+
runs-on: ubuntu-latest
35+
strategy:
36+
fail-fast: false
37+
matrix:
38+
toolchain: ${{ fromJson( needs.noir-version-list.outputs.noir_versions )}}
39+
include:
40+
- toolchain: nightly
41+
steps:
42+
- name: Checkout sources
43+
uses: actions/checkout@v4
44+
45+
- name: Install Nargo
46+
uses: noir-lang/[email protected]
47+
with:
48+
toolchain: ${{ matrix.toolchain }}
49+
50+
- name: Run Noir tests
51+
run: nargo test
52+
53+
rust-equivalence-tests:
54+
name: Test for equivalence against Rust impl
55+
runs-on: ubuntu-latest
56+
steps:
57+
- name: Checkout sources
58+
uses: actions/checkout@v4
59+
60+
- name: Install Nargo
61+
uses: noir-lang/[email protected]
62+
with:
63+
toolchain: ${{ env.MINIMUM_NOIR_VERSION }}
64+
65+
- name: Install Cargo
66+
uses: dtolnay/[email protected]
67+
with:
68+
targets: x86_64-unknown-linux-gnu
69+
70+
- name: Cache Cargo dependencies
71+
uses: Swatinem/rust-cache@v2
72+
with:
73+
key: x86_64-unknown-linux-gnu
74+
cache-on-failure: true
75+
76+
- name: Export and Test Noir Functions
77+
run: ./scripts/fuzz-test.sh
78+
79+
format:
80+
runs-on: ubuntu-latest
81+
steps:
82+
- name: Checkout sources
83+
uses: actions/checkout@v4
84+
85+
- name: Install Nargo
86+
uses: noir-lang/[email protected]
87+
with:
88+
toolchain: ${{ env.MINIMUM_NOIR_VERSION }}
89+
90+
- name: Run formatter
91+
run: nargo fmt --check
92+
93+
# This is a job which depends on all test jobs and reports the overall status.
94+
# This allows us to add/remove test jobs without having to update the required workflows.
95+
tests-end:
96+
name: Noir End
97+
runs-on: ubuntu-latest
98+
# We want this job to always run (even if the dependant jobs fail) as we want this job to fail rather than skipping.
99+
if: ${{ always() }}
100+
needs:
101+
- test
102+
- rust-equivalence-tests
103+
- format
104+
105+
steps:
106+
- name: Report overall success
107+
run: |
108+
if [[ $FAIL == true ]]; then
109+
exit 1
110+
else
111+
exit 0
112+
fi
113+
env:
114+
# We treat any cancelled, skipped or failing jobs as a failure for the workflow as a whole.
115+
FAIL: ${{ contains(needs.*.result, 'failure') || contains(needs.*.result, 'cancelled') || contains(needs.*.result, 'skipped') }}

‎.gitignore‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
target
2+
export
3+
gates_report.json

‎.release-please-manifest.json‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
{".": "0.0.0"}

‎CONTRIBUTING.md‎

Lines changed: 89 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,89 @@
1+
# Contributing
2+
3+
Thank you for your interest in contributing! We value your contributions. 🙏
4+
5+
This guide will discuss how the team handles [Commits](#commits), [Pull Requests](#pull-requests), [Releases](#releases), the [Changelog](#changelog), and [Response time](#response-time).
6+
7+
**Note:** We won't force external contributors to follow this verbatim, but following these guidelines definitely helps us in accepting your contributions.
8+
9+
## Commits
10+
11+
We want to keep our commits small and focused. This allows for easily reviewing individual commits and/or splitting up pull requests when they grow too big. Additionally, this allows us to merge smaller changes quicker.
12+
13+
When committing, it's often useful to use the `git add -p` workflow to decide on what parts of the changeset to stage for commit.
14+
15+
## Pull Requests
16+
17+
Before you create a pull request, search for any issues related to the change you are making. If none exist already, create an issue that thoroughly describes the problem that you are trying to solve. These are used to inform reviewers of the original intent and should be referenced via the pull request template.
18+
19+
Pull Requests should be focused on the specific change they are working towards. If prerequisite work is required to complete the original pull request, that work should be submitted as a separate pull request.
20+
21+
This strategy avoids scenarios where pull requests grow too large/out-of-scope and don't get proper reviews—we want to avoid "LGTM, I trust you" reviews.
22+
23+
### Conventional Commits
24+
25+
We use [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) naming conventions for PRs, which help with releases and changelogs. Please use the following format for PR titles:
26+
27+
```
28+
<type>[optional scope]: <description>
29+
```
30+
31+
Generally, we want to only use the three primary types defined by the specification:
32+
33+
- `feat:` - This should be the most used type, as most work we are doing in the project are new features. Commits using this type will always show up in the Changelog.
34+
- `fix:` - When fixing a bug, we should use this type. Commits using this type will always show up in the Changelog.
35+
- `chore:` - The least used type, these are not included in the Changelog unless they are breaking changes. But remain useful for an understandable commit history.
36+
37+
#### Breaking Changes
38+
39+
Annotating BREAKING CHANGES is extremely important to our release process and versioning. To mark a commit as breaking, we add the ! character after the type, but before the colon. For example:
40+
41+
```
42+
feat!: Rename nargo build to nargo check (#693)
43+
```
44+
45+
```
46+
feat(nargo)!: Enforce minimum rustc version
47+
```
48+
49+
#### Scopes
50+
51+
Scopes significantly improve the Changelog, so we want to use a scope whenever possible. If we are only changing one part of the project, we can use the name of the crate, like (nargo) or (noirc_driver). If a change touches multiple parts of the codebase, there might be a better scope, such as using (syntax) for new language features.
52+
53+
```
54+
feat(nargo): Add support for wasm backend (#234)
55+
```
56+
57+
```
58+
feat(syntax): Implement String data type (#123)
59+
```
60+
61+
### Typos and other small changes
62+
63+
Significant changes, like new features or important bug fixes, typically have a more pronounced impact on the project’s overall development. For smaller fixes, such as typos, we encourage you to report them as Issues instead of opening PRs. This approach helps us manage our resources effectively and ensures that every change contributes meaningfully to the project. PRs involving such smaller fixes will likely be closed and incorporated in PRs authored by the core team.
64+
65+
### Reviews
66+
67+
For any repository in the organization, we require code review & approval by **one** team member before the changes are merged, as enforced by GitHub branch protection. Non-breaking pull requests may be merged at any time. Breaking pull requests should only be merged when the team has general agreement of the changes and is preparing a breaking release.
68+
69+
### Documentation
70+
71+
Breaking changes must be documented, either through adding/updating existing docs or README.md.
72+
73+
## Releases
74+
75+
Releases are managed by [Release Please](https://github.com/googleapis/release-please) which runs in a GitHub Action whenever a commit is made on the master branch.
76+
77+
Release Please parses Conventional Commit messages and opens (or updates) a pull request against the master branch that contains updates to the versions & Changelog within the project. If it doesn't detect any breaking change commits, it will only increment the "patch" version; however, if it detects a breaking change commit, it will increment the "minor" version number to indicate a breaking release.
78+
79+
When we are ready to release the version, we approve and squash merge the release pull request into master. Release Please will detect this merge and generate the appropriate tags for the release. Additional release steps may be triggered inside the GitHub Action to automate other parts of the release process.
80+
81+
There is no strict release cadence, but a new release is usually cut every 1 to 2 months.
82+
83+
## Changelog
84+
85+
The Changelog is automatically managed by Release Please and informed by the Conventional Commits (as discussed above).
86+
87+
## Response time
88+
89+
The team will respond to issues and PRs within 1 week from submission.

0 commit comments

Comments
 (0)