pezkuwichain/pezkuwi-sdk
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

fix: Resolve cargo clippy errors and add CI workflow plan

Browse Source 
## Changes

### Clippy Fixes
- Fixed deprecated `cargo_bin` usage in 27 test files (added #![allow(deprecated)])
- Fixed uninlined_format_args in zombienet-sdk-tests
- Fixed subxt API changes in revive/rpc/tests.rs (fetch signature, StorageValue)
- Fixed dead_code warnings in validator-pool and identity-kyc mocks
- Fixed field name `i` -> `_i` in tasks example

### CI Infrastructure
- Added .claude/WORKFLOW_PLAN.md for tracking CI fix progress
- Updated lychee.toml and taplo.toml configs

### Files Modified
- 27 test files with deprecated cargo_bin fix
- bizinikiwi/pezframe/revive/rpc/src/tests.rs (subxt API)
- pezkuwi/pezpallets/validator-pool/src/{mock,tests}.rs
- pezcumulus/teyrchains/pezpallets/identity-kyc/src/mock.rs
- bizinikiwi/pezframe/examples/tasks/src/tests.rs

## Status
- cargo clippy: PASSING
- Next: cargo fmt, zepter, workspace checks
This commit is contained in:
Kurdistan Tech Ministry
2025-12-22 16:36:14 +03:00
parent 8acf59c6aa
commit 65b7f5e640
1393 changed files with 17834 additions and 179151 deletions
Download Patch File Download Diff File Expand all files Collapse all files
vendor/pezkuwi-subxt/RELEASING.md
Vendored
-108
View File
@@ -1,108 +0,0 @@
# Release Checklist
These steps assume that you've checked out the Subxt repository and are in the root directory of it.
We also assume that ongoing work done is being merged directly to the `master` branch.
1. Ensure that everything you'd like to see released is on the `master` branch.
2. Create a release branch off `master`, for example `release-v0.17.0`. Decide how far the version needs to be bumped based
on the changes to date. If unsure what to bump the version to (e.g. is it a major, minor or patch release), check with the
Parity Tools team.
3. Check that you're happy with the current documentation.
```
cargo doc --open
```
CI checks for broken internal links at the moment. Optionally you can also confirm that any external links
are still valid like so:
```
cargo install cargo-deadlinks
cargo deadlinks --check-http
```
If there are minor issues with the documentation, they can be fixed in the release branch.
4. Bump the crate versions in the root `Cargo.toml` to whatever was decided in step 2 (basically a find and replace from old version to new version in this file should do the trick).
5. Ensure the `Cargo.lock` file is up to date.
```
cargo generate-lockfile
```
6. Update `CHANGELOG.md` to reflect the difference between this release and the last. If you're unsure of
what to add, check with the Tools team. See the `CHANGELOG.md` file for details of the format it follows.
First, if there have been any significant changes, add a description of those changes to the top of the
changelog entry for this release.
Next, you can use the following script to generate the merged PRs between releases:
```
./scripts/generate_changelog.sh
```
Ensure that the script picked the latest published release tag (e.g. if releasing `v0.17.0`, the script should
provide `[+] Latest release tag: v0.16.0` ). Then group the PRs into "Fixed", "Added" and "Changed" sections, and make any
other adjustments that you feel are necessary for clarity.
7. If any of the differences impact the minimum version of `rustc` that the code will run on, please update the `rust-version`
field in the root `Cargo.toml` accordingly.
8. Commit any of the above changes to the release branch and open a PR in GitHub with a base of `master`.
9. Once the branch has been reviewed and passes CI, merge it.
10. Now, we're ready to publish the release to crates.io.
1. Checkout `master`, ensuring we're looking at that latest merge (`git pull`).
```
git checkout master && git pull
```
2. Perform a final sanity check that everything looks ok.
```
cargo test --all-targets
```
3. Run the following command to publish each crate in the required order (allowing
a little time in between each to let crates.io catch up with what we've published).
```
(cd utils/strip-metadata && cargo publish) && \
(cd metadata && cargo publish) && \
(cd lightclient && cargo publish) && \
(cd utils/fetch-metadata && cargo publish) && \
(cd codegen && cargo publish) && \
(cd macro && cargo publish);
```
Now, remove the dev dependencies from `subxt-core` (to avoid circular deps), and then run:
```
(cd core && cargo publish) && \
(cd rpcs && cargo publish) && \
(cd subxt && cargo publish) && \
(cd signer && cargo publish) && \
(cd cli && cargo publish);
```
Finally, put back the dev dependencies in `subxt-core`.
11. If the release was successful, tag the commit that we released in the `master` branch with the
version that we just released, for example:
```
git tag -s v0.17.0 # use the version number you've just published to crates.io, not this one
git push --tags
```
Once this is pushed, go along to [the releases page on GitHub](https://github.com/paritytech/subxt/releases)
and draft a new release which points to the tag you just pushed to `master` above. Copy the changelog comments
for the current release into the release description.