-
Notifications
You must be signed in to change notification settings - Fork 17
Overhaul CI with Makefile #51
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.
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
Conversation
fa557e4 to
8e88243
Compare
|
Opening this up to see what you guys think! The diff is pretty nice. 😊 |
grod220
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cargo-make for the win!
1ec9fa4 to
6699269
Compare
grod220
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Think this is really great!
lorisleiva
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've got mixed feelings about this but I think it is a net improvement for this repository considering most of the bells and whistles from the zx scripts and the special Cargo.toml variables where not really used as much anyway.
The previous scripting implementation was providing a mini-framework within your repository to inject features into your workflow in a way that would automatically be picked up by CI. But on the flip side, there is decent amount of overhead in having that extra complexity on each repo and having to keep that mini-framework in sync between them.
I'd say I'm in favour of this change. I'm looking forward to see how it adapts to different repos with different needs and then perhaps we can find a good strategy for using it in the create-solana-program generator.
dev.env
Outdated
| RUST_TOOLCHAIN_NIGHTLY="nightly-2024-11-22" | ||
| SOLANA_TOOLCHAIN="2.2.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this information also on the workspace Cargo file which used to be the source of truth for env configs like this? If this is changing that source of truth, should we consider removing that information from the Cargo file so we don't have to keep them in sync?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! I probably forgot to cut it from Cargo.toml.
| "solana:check": "tsx ./scripts/helpers/check-solana-version.mts", | ||
| "solana:link": "tsx ./scripts/helpers/link-solana-version.mts", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might have missed it but I don't think these command have replacements. They seem to be just removed from the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's correct, I felt like they weren't really necessary. If I'm wrong, we can add them back!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm fine not having it back. It was just a useful thing to ensure your local Solana version matches the project requirements but tbh this is probably best as a user-based utility instead.
| "interface:publish": "tsx ./scripts/rust.mts publish interface", | ||
| "interface:test": "tsx ./scripts/rust.mts test interface", | ||
| "interface:wasm": "tsx ./scripts/rust.mts wasm interface", | ||
| "template:upgrade": "tsx ./scripts/helpers/upgrade-template.ts" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same for this command which doesn't seem to be replaced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is not quite equivalent to its zx variant (no checking for additional account or program addresses to load from the program Cargo files) but here it's okay because the system program wasn't making use of its features.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right yeah, I also simplified it a bit. Sorry, I should have called that out!
Just pointing out that I'm not advocating for this to be used in the template generator. It's certainly possible, but my goal here was to simplify only our stuff for the time being. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be honest, I think we'd almost be better off with an old-school Makefile, since we're not really using any of the special features of cargo-make.
I don't want to derail the effort too much, but this mimics most of the functionality:
nightly = +nightly-2024-11-22
clippy-%:
cargo $(nightly) clippy --manifest-path $(subst -,/,$*)/Cargo.toml
clippy-%-fix:
cargo $(nightly) clippy --fix --manifest-path $(subst -,/,$*)/Cargo.toml
format-%:
cargo $(nightly) fmt --check --manifest-path $(subst -,/,$*)/Cargo.toml
format-%-fix:
cargo $(nightly) fmt --manifest-path $(subst -,/,$*)/Cargo.toml
features-%:
cargo $(nightly) hack check --feature-powerset --all-targets --manifest-path $(subst -,/,$*)/Cargo.toml
publish-%:
./scripts/publish-rust.sh $(subst -,/,$*)
build-wasm-interface:
wasm-pack build --target nodejs --dev ./interface --features bincode
lint-docs-%:
RUSTDOCFLAGS="--cfg docsrs -D warnings" cargo $(nightly) doc --all-features --no-deps --manifest-path $(subst -,/,$*)/Cargo.toml
test-%:
cargo $(nightly) test --manifest-path $(subst -,/,$*)/Cargo.toml
format-js:
cd ./clients/js && pnpm install && pnpm format
test-js:
./scripts/start-test-validator.sh
cd ./clients/js && pnpnm install && pnpm build && pnpm test
./scripts/stop-test-validator.sh
So you can run make lint-clients-rust or make lint-interface, and then anyone can run this without additional software.
If you think that's a bit too much though, we can go with this approach.
Nice. I'm honestly cool with a Makefile as well. That eliminates the requirement to install the cargo-make binary and it also doesn't add any extra terminal output, which is an annoying feature of cargo-make. The generic aliasing ( |
I'm glad that I didn't waste too much time figuring out how to make it work then 😅 shall I put up a PR with the Makefile? |
If you want, you can add it to this PR, and I'll just address the bash feedback? |
|
Works for me! |
buffalojoec
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't approve, since I wrote it, but the Makefile changes LGTM!
joncinque
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
Originally this PR overhauled the repository's CI, including scripts and
pnpmworkspace configurations, withcargo-make.See discussion below, where we transitioned to a Makefile.