Turing.jl icon indicating copy to clipboard operation
Turing.jl copied to clipboard

CompatHelper: bump compat for OptimizationOptimJL to 0.4 for package test, (keep existing compat)

Open github-actions[bot] opened this issue 1 year ago • 4 comments

This pull request changes the compat entry for the OptimizationOptimJL package from 0.1, 0.2, 0.3 to 0.1, 0.2, 0.3, 0.4 for package test. This keeps the compat entries for earlier versions.

Note: I have not tested your package with this new compat entry. It is your responsibility to make sure that your package tests pass before you merge this pull request.

github-actions[bot] avatar Sep 27 '24 00:09 github-actions[bot]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 86.80%. Comparing base (3c91eec) to head (92ec34d). Report is 6 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2353      +/-   ##
==========================================
- Coverage   86.86%   86.80%   -0.07%     
==========================================
  Files          24       24              
  Lines        1599     1599              
==========================================
- Hits         1389     1388       -1     
- Misses        210      211       +1     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

codecov[bot] avatar Sep 27 '24 02:09 codecov[bot]

Is there a way to open an aggregated PR for these dependencies upgrades? If not, we could contribute a feature to CompatHelper.

@penelopeysm @devmotion any thoughts?

yebai avatar Sep 27 '24 10:09 yebai

That thought has struck me, but I think it's impossible for an automated tool to figure out which of the PRs are related and should be aggregated. Although grouping multiple PRs into one is fairly easy (create a new branch -> merge PRs into that branch -> open a new PR from that branch back to master), the converse problem of breaking up a PR is actually more annoying to deal with (git reset HEAD~ -> git add -p which often isn't granular enough -> reopen PRs) so we wouldn't want that either.

The closest compromise I can think of is if the same dependency is being bumped in the main package + tests, then group those. That could be an optional flag for CompatHelper.main()

penelopeysm avatar Sep 27 '24 10:09 penelopeysm

Pull Request Test Coverage Report for Build 11062381193

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.06%) to 87.022%

Totals Coverage Status
Change from base Build 11050401755: -0.06%
Covered Lines: 1388
Relevant Lines: 1595

💛 - Coveralls

coveralls avatar Sep 27 '24 12:09 coveralls