* add cargo update steps to task list
* Fix a formatting issue in the checklist
* Apply suggestions from code review
Co-authored-by: teor <teor@riseup.net>
---------
Co-authored-by: teor <teor@riseup.net>
* add user agent as argument, use git to auto build zebra user agent
* try to fix test
* fix typo
* change expect text
* remove newline
* fix some docs
Co-authored-by: Marek <mail@marek.onl>
---------
Co-authored-by: Marek <mail@marek.onl>
* Split checking for cached state disks into its own workflow
* Fix workflow field order
* Run the top-level workflow when the reusable workflow changes
* And run dependent workflows for pull requests as well
* Remove redundant output names
* Document the existing and new workflow jobs
* Add the network to the "no disk found" message
* Tweak existing docs and descriptions
* Generate Zebra checkpoints on testnet
* Add a full sync testnet entrypoint, and simplify mainnet env vars
* Only run the full testnet sync on the main branch
* Deduplicate and update the zebra-checkpoints docs
* Add instructions for automatic checkpoint generation
* Hide some details in the release checklist
* Update release checkpoint instructions to use CI
* Only update the cache in one job on mainnet
* refuse to run Zebra if it is too old
* update the release checklist to consider the constants
* bring newline back
* apply new end of support code
* attempt to add tests (not working yet)
* move eos to progress task
* move tests
* add acceptance test (not working)
* fix tests
* change to block height checks (ugly code)
* change warn days
* refactor estimated blocks per day, etc
* move end of support code to its own task
* change test
* fix some docs
* move constants
* remove uneeded conversions
* downgrade tracing
* reduce end of support time, fix ci changing debugs to info again
* update instructions
* add failure messages
* cargo lock update
* unify releaase name constant
* change info msg
* clippy fixes
* add a block explorer
* ignore testnet in end of support task
* change panic to 16 weeks
* add some documentation about end of support
* Tweak docs wording
---------
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Changelog with trivial entries
* Delete trivial entries
* Summarise known issues in README, but don't change the list yet
* Add block timeouts to known issues
* Update the release template to add missing version files
* Bump crate versions
* Add the required Rust version to the release checklist
* Update the Rust version requirement to 1.65, Zebra now uses `let ... else ...`
* Update checkpoints
* Add checkpoints to the CHANGELOG
* Breaking Rust compiler version change
* Clarify the latest stable supported rust version
* Update release-checklist.md
* Add complex code or requirements to the PR template
* Add complex code and testing sections to the ticket template
Remove the design section, because we're not using it
* Merge freeze and merge PRs
* Fix the branch name in the release template
* Use a docker command with colour and Ctrl-C support
* Make branch name example more readable
* Fix a link typo
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* docs: add user documentation on how to use Zebra with docker
Motivation:
We don't have a user documentation on how to use/deploy Zebra using our
the Dockerfile available in our repository or were the images are being
hosted
Solution:
Add user documentation explaining how to pull the image from the Docker
Hub or how to build it locally. With extra information on which images
we're hosting and where we're hosting it
* docs(docker): use existing getting started header
* Update book/src/user/docker.md
Co-authored-by: Arya <aryasolhi@gmail.com>
* docs(docker): add build alternative instructions from Docker
* docs: add docker documentation to Rust doc sidebar
* docs: update checklist with docker user documentation
* Update README.md
Co-authored-by: teor <teor@riseup.net>
* Update new refs to rc.1
Co-authored-by: Arya <aryasolhi@gmail.com>
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Increment Zebra versions
* Initial draft changelog
* Add blog post to the release checklist
* Say "user testing"
Co-authored-by: teor <teor@riseup.net>
* Add a Docker run command to the README
* Update the README with some user-relevant release candidate goals
* Update the release template for the release candidate
* Fix beta crate explanation
* Be more specific about what "this PR" means
* Update docker command for latest tag changes
* Update README Docker command based on tag changes
* Make Zebra release versions more vague in README.md
Co-authored-by: Pili Guerra <mpguerra@users.noreply.github.com>
* Move build instructions to build section
Co-authored-by: Pili Guerra <mpguerra@users.noreply.github.com>
* Add newlines to separate heading and paragraphs
* Remove extra newline
* Add a note for a future command update
* Remove manual build check, it doesn't have tier 1 support
Co-authored-by: Pili Guerra <mpguerra@users.noreply.github.com>
* Explain how to use the release template
I always have to look this up every time.
Also delete a long description of semantic versioning.
* Delete extra info that is already in the template elsewhere
* Explain how `Cargo.lock` gets updated
* Use a branch name that Google Cloud will accept
* Update release instructions for Docker binaries
* Add extra release testing steps
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Gustavo Valverde <gustavo@iterativo.do>
* Update release-drafter.yml
* Explain where we got the workflow from
* Automatically add "trivial" label to dependabot updates
* Add categories and auto-labels to release drafter
* Update release PR template for automatic release drafter versions
* Also strip PR series numbers and leading spaces from changelog entries
* Update release note version check
* Update label names
* Add missing ! in conventional commits regex
Co-authored-by: Marek <mail@marek.onl>
* Make versioning steps more specific
Co-authored-by: Marek <mail@marek.onl>
* Remove conflicting detailed versioning explanations
Co-authored-by: Marek <mail@marek.onl>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
* Make the release checklist shorter and hide some details
* Ignore any `fastmod` updates to previous release notes in `CHANGELOG.md`
* Use recent versions in examples
* Fix markdown that doesn't render correctly
* Fix some weird line breaks
* Use capital letters to start list items
* Clarify `fastmod` and `CHANGELOG.md`
* Clarify version format by changing highlighting
* change(doc): add item to release checklist to update dependencies in the README
* Update .github/PULL_REQUEST_TEMPLATE/release-checklist.md
Co-authored-by: Marek <mail@marek.onl>
Co-authored-by: Marek <mail@marek.onl>
* Update changelog for v1.0.0-beta.7
* Increment all crate versions
* Remove redundant release test that is now covered by CI
* Remove completed NU5 README check task from the release template
* Add Merge Freeze tool to the release checklist
* Simplify release checklist by removing unused steps
* Move `MockedClientHandle` to `peer` module
It's more closely related to a `Client` than the `PeerSet`, and this
prepares it to be used by other tests.
* Rename `MockedClientHandle` to `ClientTestHarness`
Reduce confusion, and clarify that the client is not mocked.
Co-authored-by: teor <teor@riseup.net>
* Add clarification to `mock_peers` documentation
Explicitly say how the generated data is returned.
* Rename method to `wants_connection_heartbeats`
The `Client` service only represents one direction of a connection, so
`is_connected` is not the exact term.
Co-authored-by: teor <teor@riseup.net>
* Mock `Client` instead of `LoadTrackedClient`
Move where the conversion from mocked `Client` to mocked
`LoadTrackedClient` in order to make the test helper more easily used by
other tests.
* Use `ClientTestHarness` in `initialize` tests
Replace the boilerplate code to create a fake `Client` instance with
usages of the `ClientTestHarness` constructor.
* Allow receiving requests from `Client` instance
Create a helper type to wrap the result, to make it easier to assert on
specific events after trying to receive a request.
* Allow inspecting the current error in the slot
Share the `ErrorSlot` between the `Client` and the handle, so that the
handle can be used to inspect the contents of the `ErrorSlot`.
* Allow placing an error into the `ErrorSlot`
Assuming it is initially empty. If it already has an error, the code
will panic.
* Allow gracefully closing the request receiver
Close the endpoint with the appropriate call to the `close()` method.
* Allow dropping the request receiver endpoint
Forcefully closes the endpoint.
* Rename field to `client_request_receiver`
Also rename the related methods to include
`outbound_client_request_receiver` to make it more precise.
Co-authored-by: teor <teor@riseup.net>
* Allow dropping the heartbeat shutdown receiver
Allows the `Client` to detect that the channel has been closed.
* Rename fn. to `drop_heartbeat_shutdown_receiver`
Make it clear that it affects the heartbeat task.
Co-authored-by: teor <teor@riseup.net>
* Move `NowOrLater` into a new `now-or-later` crate
Make it easily accessible to other crates.
* Add `IsReady` extension trait for `Service`
Simplifies checking if a service is immediately ready to be called.
* Add extension method to check for readiness error
Checks if the `Service` isn't immediately ready because a call to
`ready` immediately returns an error.
* Rename method to `is_failed`
Avoid negated method names.
Co-authored-by: teor <teor@riseup.net>
* Add a `IsReady::is_pending` extension method
Checks if a `Service` is not ready to be called.
* Use `ClientTestHarness` in `Client` test vectors
Reduce repeated code and try to improve readability.
* Create a new `ClientTestHarnessBuilder` type
A builder to create test `Client` instances using mock data which can be
tracked and manipulated through a `ClientTestHarness`.
* Allow configuring the `Client`'s mocked version
Add a `with_version` builder method.
* Use `ClientTestHarnessBuilder` in `PeerVersions`
Use the builder to set the peer version, so that the `version` parameter
can be removed from the constructor later.
* Use a default mock version where possible
Reduce noise when setting up the harness for tests that don't really
care about the remote peer version.
* Remove `Version` parameter from the `build` method
The `with_version` builder method should be used instead.
* Fix some typos and outdated info in the release checklist
* Add extra client tests for zero and multiple readiness checks (#3273)
And document existing tests.
* Replace `NowOrLater` with `futures::poll!` (#3272)
* Replace NowOrLater with the futures::poll! macro in zebrad
* Replace NowOrLater with the futures::poll! macro in zebra-test
* Remove the now-or-later crate
* remove unused imports
* rustfmt
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: Alfredo Garcia <oxarbitrage@gmail.com>
Zebra's latest beta continues implementing zero-knowledge proof and note commitment tree validation. In this release, we have finished implementing transaction header, transaction amount, and Zebra-specific NU5 validation. (NU5 mainnet validation is waiting on an `orchard` crate update, and some consensus parameter updates.)
We also fix a number of security issues that could pose a local denial of service risk, or make it easier for an attacker to make a node follow a false chain.
As of this release, Zebra will automatically download and cache the Sprout and Sapling Groth16 circuit parameters. The cache uses around 1 GB of disk space. These cached parameters are shared across all Zebra and `zcashd` instances run by the same user.
See CHANGELOG.md for the full list of changes in this release.
* Update versions for zebra v1.0.0-alpha.12 release
* Update Cargo.lock
* Update release checklist with latest version changes to help keep track for future releases
* Remove reference to the fact that tower-fallback was not updated
* Add new CHANGELOG.md file to zebra git repo
* Update Release Checklist to add updates to CHANGELOG.md
* Add some explanation about the CHANGELOG.md file
* Fix headings to make them consistent with Keep a changelog format
* Small fix for clarity
* Add release dates to changelog
* Change order of steps to update the changelog
Updates:
- GitHub Issue templates
- GitHub PR templates
- RFC template
Focusing on:
- consensus rule / network reference sections
- design sections
- review/test checklist
Process changes:
- add new team members to RFC approval
- change RFC approval to "most of the team"
And general cleanup:
- delete docs from the checklist, because we now `warn(missing_docs)`
- shorter explanations
- consistent headings
- consistent order
- consistent formatting
* build(deps): bump vergen from 3.2.0 to 5.1.1
* fix hardcoded version for Tracing struct
* add additional metadata
* remove extra allocations for metadata
* Remove zebrad code version from release checklist
The zebrad code automatically uses the crate version now.
* Sort panic metadata into rough categories
Co-authored-by: teor <teor@riseup.net>
* Add draft PR template for release checklist
* Add some notes about keepachangelog categories
* Add excessive detail to the release checklist
We want to be very clear about the process now,
so we get consistency, and so other developers
can follow it.
Eventually, these details should move to the
developer book.
* Add links for Release Drafter and the GitHub Releases location
Co-authored-by: teor <teor@riseup.net>
Alfredo Garcia
teor
Deirdre Connolly
Gustavo Valverde
Arya
Marek
Conrado Gouvea
Janito Vaqueiro Ferreira Filho
Pili Guerra
Kirill Fomichev
Deirdre Connolly