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.

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

ci: Refactor scripts #60

Open
wants to merge 29 commits into
base: main
Choose a base branch
from
Open

ci: Refactor scripts #60

wants to merge 29 commits into from

Conversation

febo
Copy link
Collaborator

@febo febo commented Feb 6, 2025

Problem

CI currently has limited checks and the publish.yml workflow is limited to a couple of crates.

Solution

Refactor the CI. This involved using a new set of supporting scripts, which can also be used from the command-line:

  • audit: audit dependencies of the workspace
  • build: build a crate with build-sbf (useful to detect issues with code under the target = solana configuration
  • clippy: run clippy
  • doc: linting of doc sections
  • format: run cargo fmt
  • hack: linting of feature powerset
  • lint: execute clippy && doc && hack in sequence
  • semver: semantic versioning validation
  • test: run cargo test

CI make use of these scripts to run:

  1. audit
  2. For each crate of the repository, it executes:
    • format
    • clippy
    • doc
    • hack
    • build
    • test

The publish.yml workflow was updated to work with any crate of the reposiroty and incorporates semver-checks based on the version level. If the version level selected for publishing violates semantic versioning, the publishing fails. For example, if the code to be published under a patch version contains breaking changes, the semver-check will fail and the publish workflow will abort.

Note

The code in main is currently failing the doc linting - #64 fixes these issues.

@febo febo force-pushed the febo/refactor-ci branch from c2ad80e to 6be0456 Compare February 6, 2025 14:47
@febo febo force-pushed the febo/refactor-ci branch from 8bb36fb to 20e4cfb Compare February 6, 2025 16:17
@febo febo force-pushed the febo/refactor-ci branch from 20e4cfb to 4f7ad78 Compare February 6, 2025 18:07
@febo febo marked this pull request as ready for review February 7, 2025 23:03
@febo febo requested a review from joncinque February 7, 2025 23:06
@febo
Copy link
Collaborator Author

febo commented Feb 8, 2025

Just realised that the "filter" is not as precise as it should be. For example, when the main pinocchio crate changes, all crates that depend on it should also go through the CI checks – this is not happening with the current filter.

Update: The conditional filter was removed.

Copy link
Collaborator

@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.

Nothing show-stopping, mostly small questions -- looks great!

Comment on lines +78 to +79
- name: build-sbf
run: pnpm build ${{ matrix.member }}
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: How about calling the script build-sbf to make things clearer?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yep, definitely clearer.

Comment on lines +73 to +76
- name: Set Git Author
run: |
git config --global user.email "github-actions@github.com"
git config --global user.name "github-actions"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Sorry for fish brain: this is used so that the github-actions bot doesn't appear as a contributor, correct? Why was this a problem again?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, using these labels, the "github-actions" does not appear as a contributor. It does not solve a particular problem, it is a cosmetic thing. Happy to revert the change.

@@ -17,5 +17,14 @@ repository = "https://github.com/anza-xyz/pinocchio"

[workspace.dependencies]
five8_const = "0.1.3"
pinocchio = { path = "sdk/pinocchio", version = ">= 0.6, <= 0.7" }
pinocchio-pubkey = { path = "sdk/pubkey", version = "0.2.1" }
pinocchio = { path = "sdk/pinocchio", version = ">= 0.6" }
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why is the version specified like that?

Copy link
Collaborator Author

@febo febo Feb 11, 2025

Choose a reason for hiding this comment

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

This is probably me not using the workspace dependencies correctly. I was trying to avoid bumping dependencies on other packages unnecessarily. For example, if pinocchio-pubkey can work with multiple versions of pinocchio and pinocchio has been bumped to 0.7, I still want to specify that pinocchio-pubkey works with anything from >= 0.6.

But perhaps this is not the correct way to do that.

"private": true,
"scripts": {
"audit": "tsx ./scripts/audit.mjs",
"build": "tsx ./scripts/build.mjs",
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: mentioned earlier, but build-sbf would probably be clearer


const [folder, ...args] = cliArguments();

const buildArgs = [...args, '--', '--all-targets', '--all-features'];
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm surprised to see --all-targets here -- I tried building a couple of programs with cargo build-sbf -- --all-targets and it fails because some dependencies that are incompatible with the chain are probably brought in.

Is that what you're trying to test here? It's pretty cool!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, it is a sanity check.


- name: Check semver
uses: obi1kenobi/cargo-semver-checks-action@v2
run: |
pnpm semver ${{ inputs.crate }} --release-type ${{ inputs.level }}
Copy link
Collaborator

Choose a reason for hiding this comment

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

That's really neat, I didn't know it could do that!

Comment on lines +95 to +97
- name: Push Commit and Tag
if: github.event.inputs.dry_run != 'true'
run: git push origin --follow-tags
Copy link
Collaborator

Choose a reason for hiding this comment

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

It's up to you, but I prefer to use the functionality from cargo release to tag and push, ie: https://github.com/solana-program/token-2022/blob/a46685f457db8e5c68d7f43e1c032500b7cd258b/scripts/rust/publish.mjs#L24

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh, that is better, I will change it so it does the same thing.

Comment on lines +46 to +53
// Soft reset the last commit so we can create our own commit and tag.
await $`git reset --soft HEAD~1`;

// Commit the new version.
await $`git commit -am "Publish ${crate} v${version}"`;

// Tag the new version.
await $`git tag -a ${crate}@v${version} -m "${crate} v${version}"`;
Copy link
Collaborator

Choose a reason for hiding this comment

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

As flagged earlier, if you decide to update the flags to cargo release, you don't need to do any of this: https://github.com/solana-program/token-2022/blob/a46685f457db8e5c68d7f43e1c032500b7cd258b/scripts/rust/publish.mjs#L24

Be careful to specify two curly braces around {{version}} since that actually interpolates the version that the repo will be bumped to

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.

2 participants