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.

Sign up for GitHub

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

README cleanup #489

Merged
merged 2 commits into from
Nov 12, 2024
Merged

README cleanup #489

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
5e93ba5
Remove old references to toolchain and release process
r-n-o Nov 11, 2024
49714d6
Update instructions to submit a PR
r-n-o Nov 11, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 0 additions & 28 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -129,32 +129,4 @@ make TARGET=generic
make run
```

#### Enter shell in toolchain environment
```
make toolchain-shell
```

#### Update toolchain dependency pins
```
make toolchain-update
```


### Release Process

0. Determine the release semver version by consulting the [changelog](./CHANGELOG.MD).
1. Create a branch for your release e.g.
`git checkout -b release/v1.0.0`
2. Run `make dist` as described in ["Release" section](#release)
3. Commit the new dist folder `git commit -m "Release v1.0.0" -- dist/`
4. Push up your branch to github, and make a pull request.
5. You may also create and push a signed `-rcX` git tag where the number after `rc` doesn't already exist.
`git tag -S v1.0.0-rc0 -m v1.0.0-rc0`
`git push origin v1.0.0-rc0`
6. Wait for others to replicate your build, see ["Verify" section](#verify)
7. Once the release has enough `git sig` signatures, make the final tag and merge the pull request.
`git tag -S v1.0.0 -m v1.0.0`
`git push origin v1.0.0`


[gs]: https://codeberg.org/distrust/git-sig
15 changes: 5 additions & 10 deletions src/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,21 +12,16 @@ The Quorum Key itself can be used by QuorumOS and enclave apps to encrypt and au

### Submitting a PR

Before a PR can be merged it must:

Be formatted
Before a PR can be merged you must run:

```bash
make lint
make lint # apply standardized code formatting
make test # run unit tests locally
```

And pass all tests

```bash
make test-all
```
All tests must pass.

The PR will also need to pass the `build-linux-only-crates` github workflow. There are 3 crates excluded from the rust workspace: `qos_system`, `qos_aws`, and `init`. These crates are excluded because they only build on linux. If you are not working directly with these crates they generally only need to be updated if the dependencies for `qos_core` change. The linux only crates each have their own lockfile and that will need to be up to date for deterministic builds to work. To update the locks files you will need a linux build environment. Once in a linux build enviroment you can run `make build-linux-only`, which will update lock files if neccesary; any updated lock files should then be committed.
The PR will also need to pass the `build-linux-only` github workflow. There are 3 crates excluded from the Rust workspace: `qos_system`, `qos_aws`, and `init`. These crates are excluded because they only build on Linux. If you are not working directly with these crates they generally only need to be updated if the dependencies for `qos_core` change. The linux only crates each have their own lockfile and that will need to be up to date for deterministic builds to work. To update the locks files you will need a linux build environment. Once in a linux build environment you can run `make build-linux-only`, which will update lock files if necessary; any updated lock files should then be committed.

### View the docs

Expand Down