Skip to content

Conversation

@buffalojoec
Copy link
Contributor

@buffalojoec buffalojoec commented Apr 22, 2025

Originally this PR overhauled the repository's CI, including scripts and pnpm workspace configurations, with cargo-make.

See discussion below, where we transitioned to a Makefile.

@buffalojoec buffalojoec force-pushed the cargo-make branch 7 times, most recently from fa557e4 to 8e88243 Compare April 22, 2025 16:36
@buffalojoec buffalojoec marked this pull request as ready for review April 22, 2025 16:46
@buffalojoec
Copy link
Contributor Author

Opening this up to see what you guys think! The diff is pretty nice. 😊

Copy link
Member

@grod220 grod220 left a 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!

@buffalojoec buffalojoec force-pushed the cargo-make branch 2 times, most recently from 1ec9fa4 to 6699269 Compare April 24, 2025 11:08
grod220
grod220 previously approved these changes Apr 24, 2025
Copy link
Member

@grod220 grod220 left a 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!

Copy link
Member

@lorisleiva lorisleiva left a 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
Comment on lines 1 to 2
RUST_TOOLCHAIN_NIGHTLY="nightly-2024-11-22"
SOLANA_TOOLCHAIN="2.2.0"
Copy link
Member

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?

Copy link
Contributor Author

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.

Comment on lines -4 to -5
"solana:check": "tsx ./scripts/helpers/check-solana-version.mts",
"solana:link": "tsx ./scripts/helpers/link-solana-version.mts",
Copy link
Member

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.

Copy link
Contributor Author

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!

Copy link
Member

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"
Copy link
Member

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.

Copy link
Member

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.

Copy link
Contributor Author

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!

@buffalojoec
Copy link
Contributor Author

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.

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.

Copy link
Contributor

@joncinque joncinque left a 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.

@buffalojoec
Copy link
Contributor Author

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.

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 (%) is also a nice touch!

@joncinque
Copy link
Contributor

joncinque commented May 5, 2025

The generic aliasing (%) is also a nice touch!

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?

@buffalojoec
Copy link
Contributor Author

The generic aliasing (%) is also a nice touch!

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?

@joncinque
Copy link
Contributor

Works for me!

@buffalojoec buffalojoec changed the title Overhaul CI with cargo-make Overhaul CI with Makefile May 6, 2025
Copy link
Contributor Author

@buffalojoec buffalojoec left a 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!

Copy link
Contributor

@joncinque joncinque left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great!

@buffalojoec buffalojoec merged commit 960949f into solana-program:main May 6, 2025
8 checks passed
@buffalojoec buffalojoec deleted the cargo-make branch May 6, 2025 10:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants