Skip to content

Conversation

@Pankraz76
Copy link
Contributor

@Pankraz76 Pankraz76 commented Nov 4, 2025

Description

[Describe what this change achieves]

Related Issues

Resolves #[Issue number to be closed when this PR is merged]

Check List

  • Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

follow up from:

26m 56s vs 17m 23s

image

@Pankraz76 Pankraz76 requested review from a team, jed326 and peternied as code owners November 4, 2025 13:17
@github-actions
Copy link
Contributor

github-actions bot commented Nov 4, 2025

❌ Gradle check result for 4d3b181: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@Pankraz76 Pankraz76 force-pushed the rewrite-fix-gradle branch 2 times, most recently from 575268d to 6e63234 Compare November 4, 2025 15:00
distribution: temurin
cache: gradle
- name: Run Gradle (precommit)
- name: Run Gradle (pre-commit)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

could kind of suggest this, also to be aligned with new check.

Copy link
Contributor Author

@Pankraz76 Pankraz76 left a comment

Choose a reason for hiding this comment

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

mea culpa.


public void testMaxProcesses() throws IOException, InterruptedException {
String limits = executeCommand("sudo su -c 'cat /proc/" + opensearchPid + "/limits'", "Failed to read process limits");
assertTrue("Max processes limit should be 4096 or unlimited",
Copy link
Contributor Author

@Pankraz76 Pankraz76 Nov 4, 2025

Choose a reason for hiding this comment

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

also spotless is not spotless, like anything else made by error-prone human being. mea culpa.

- name: Run Gradle (sanity-check)
continue-on-error: ${{ matrix.experimental }}
shell: bash
run: ./gradlew rewriteDryRun -Dorg.gradle.jvmargs=-Xmx8G
Copy link
Contributor Author

Choose a reason for hiding this comment

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

assuming we can reuse cached compile phase somehow.

is this actual true? kindly request @timtebeek 🍀

Choose a reason for hiding this comment

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

Don't know; haven't tried. For large projects like this one I'd advise against running against every pull request, and instead run periodically against pre-built serialized LSTs through Moderne, as it can take a long time to run here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the update. So, this means we have to rely on an externally hosted Moderne instance, right?

Yes, building on every commit doesn’t seem ideal. On the other hand, it would also be unpleasant to fix unrelated issues, and these kinds of diffs can be quite large since they don’t run on every increment. Of course, it’s very resource-intensive, but the tradeoff favors maintaining a clean state over minimizing CI costs.

The good news is that it’s running quite fast now — around 15 minutes. Six months ago, it took about 45 minutes, so there’s already been significant improvement. The sanity check also runs much faster than the current pre-commit goal, wondering what in detail it does given the long execution time.

Currently, this is handled similarly in Checkstyle and Spotless — we run and check on every increment, assuming we’re on the happy path with minimal or no changes. If that’s the case, it actually supports your approach of running these checks only occasionally rather than continuously.

However, assuming we need to relying on external resources, I’d suggest taking the strict approach for now — checking on every increment — leaving any pipeline optimization or downsizing for the future.

@github-actions
Copy link
Contributor

github-actions bot commented Nov 4, 2025

✅ Gradle check result for cda8eff: SUCCESS

@codecov
Copy link

codecov bot commented Nov 4, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.16%. Comparing base (46164b5) to head (85af591).

Additional details and impacted files
@@             Coverage Diff              @@
##               main   #19885      +/-   ##
============================================
- Coverage     73.21%   73.16%   -0.05%     
+ Complexity    71254    71182      -72     
============================================
  Files          5766     5766              
  Lines        325470   325470              
  Branches      47084    47084              
============================================
- Hits         238296   238142     -154     
- Misses        68043    68148     +105     
- Partials      19131    19180      +49     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Signed-off-by: Vincent Potucek <vpotucek@me.com>
@github-actions
Copy link
Contributor

github-actions bot commented Nov 5, 2025

✅ Gradle check result for 85af591: SUCCESS

@Pankraz76
Copy link
Contributor Author

This might be an easy starter. Rewrite has evolved, passing much quicker.

kindly request your feedback, thanks.

@andrross @sandeshkr419

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