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: slightly faster rust checks #5048

Merged
merged 3 commits into from
Feb 4, 2025
Merged

ci: slightly faster rust checks #5048

merged 3 commits into from
Feb 4, 2025

Conversation

conorsch
Copy link
Contributor

@conorsch conorsch commented Feb 4, 2025

Describe your changes

A bit of spring cleaning for the CI suite. These changes aim at faster run times on PRs, mostly via reusing common tooling, and reducing setup time. These changes don't affect which tests run, out of an abundance of caution, because we have ongoing development in a feature branch right now (#5010).

The longest-running CI check is currently the check-all-features job, which clocks in at ~14m with these changes. That's an improvement over the ~20m or so it's been taking on other PRs. For full details on the changes, see the commit messages; to summarize:

  • smoke tests use the existing tooling env
  • most checks can now be run locally via a justfile target, e.g. just check, to make CI failures more easily replicable locally
  • test names have been reformatted for readability
  • the noisy "release" checks are removed from PR runs

Overall the checks seem to complete >5m faster than before, which is good enough to merge as progress. I'm deferring more substantive changes like kicking long-running jobs to schedules, rather than on-every-PR, until we have a chance to observe these improvements over time, and until after the LQT push.

Example of CI job display before changes

pz-gh-ci-before

Example of CI job display after changes

pz-gh-ci-after

Issue ticket number and link

N/A

Checklist before requesting a review

  • If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

    ci and test code only, application logic remains unchanged

We were previously running an isolated pd & cometbft instance
specifically for the smoke tests, via process-compose. We already have
a rather robust dev-env that also leverages process-compose, but
includes auxiliary services, like metrics, postgres, and pindexer.
That dev env isn't exercised anywhere in CI, so let's reuse it
as part of the smoke test suite, which both reduces code duplication
in the test harness scripts, and opens the door to adding integration
tests for pindexer.
ci: use separate target-dir for check

In order to disallow warnings, we set `RUSTFLAGS="-D warnings"`
when running `cargo check`. Doing so, however, busts the cache,
making it impossible to reuse artifacts already built for other work.

Let's give just the check action its own cache dir, which will allow
both to exist side by side.

Breaks out the compat and feature checks into a separate job.

Also makes a few small tweaks to improve runtime throughout:

* ci: don't run release workflow on PRs

  This substnatially reduces the amount of checks per PR, which makes
  the entire test run more readable at a glance.

* ci: fix buf lint via forks

  When running in a private fork, e.g. for testing CI, the buf lint check
  will fail, because the GITHUB_REPOSITORY var points to the private repo
  URL. Instead, let's just check against the public protocol repo: that's
  really the answer we want. Doing so will display warnings if protocol
  buffer definitions break compatibility against the published main
  branch.

And renames the workflows to be more concise and readable at a glance.
Updates the pmonitor integration tests to use a feature
gate, rather than the old "ignore" pragma.

Implements a TODO in the pmonitor checks, to poll for ready state,
rather than guessing and sleeping.
@conorsch conorsch added the A-CI/CD Relates to continuous integration & deployment of Penumbra label Feb 4, 2025
@conorsch
Copy link
Contributor Author

conorsch commented Feb 4, 2025

The status checks being renamed will require an update to the branch-protection rules. The two (2) that were required were the buf checks. I can handle that in follow-up after merge.

Copy link
Contributor

@cronokirby cronokirby left a comment

Choose a reason for hiding this comment

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

LGTM

@conorsch conorsch merged commit ddca9c7 into main Feb 4, 2025
10 checks passed
@conorsch conorsch deleted the ci-faster-rust-checks branch February 4, 2025 02:06
conorsch added a commit that referenced this pull request Feb 5, 2025
Follow-up to #5009, in which these tests were introduced, and #5048,
which refactored the smoke tests to make additions like this easier.
conorsch added a commit that referenced this pull request Feb 5, 2025
## Describe your changes

Follow-up to #5009, in which these tests were introduced, and #5048,
which refactored the smoke tests to make additions like this easier.

## Issue ticket number and link
See above.

## Testing and review

The tests were already merged, this is just enabling them in CI, so CI
passing, specifically on the smoke-test job, is enough.

## Checklist before requesting a review

- [x] I have added guiding text to explain how a reviewer should test
these changes.

- [x] If this code contains consensus-breaking changes, I have added the
"consensus-breaking" label. Otherwise, I declare my belief that there
are not consensus-breaking changes, for the following reason:

  > tests/ci only, no changes to application code
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-CI/CD Relates to continuous integration & deployment of Penumbra
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants