chore(deps): update all non-major dependencies #2333
Conversation
forking-renovate
bot
added
the
renovate
renovate-bot
force-pushed
the
renovate/all-minor-patch
branch
8 times, most recently
from
95797c1
to
0c89b99
Compare
|
FYI we can't merge this until spotbugs fix their issue: spotbugs/spotbugs#2041 |
renovate-bot
force-pushed
the
renovate/all-minor-patch
branch
10 times, most recently
from
04d132e
to
8652b17
Compare
renovate-bot
force-pushed
the
renovate/all-minor-patch
branch
10 times, most recently
from
1011287
to
441eca3
Compare
renovate-bot
force-pushed
the
renovate/all-minor-patch
branch
12 times, most recently
from
d023aa3
to
c001f7b
Compare
|
I'm wondering if this new set-up where Renovate groups all minor dependency upgrades to a single PR is a good idea. Yes of course it results in a lot less PRs... but it also means that even a single issue with a single dependency then blocks the whole things from being merged. Previously 95% of these minor PRs were clear to be merged as-is - i.e. just as soon as the compile / regression test passed without issues. Now we seem to be stuck with this one huge dependency upgrade PR which is open for months and just keeps getting bigger and bigger :-) I for one would prefer the previous set-up. But not sure what others think? |
|
@ptuomola partially agreed but the amount of PR renovate raised was too much to handle. After all we need to merge dep upgrades which are currently breaking the build otherwise 4-5 PRs will just hang for a long time. I'd keep it the way it is right now. Also, this is on my todo-list, I even started to tackle this last week but ran out of time I could spare. |
Thanks @galovics. Re "amount of PR renovate raised was too much to handle" - how was this assessed? We had the previous set-up running for 2 years and I don't think it was a major issue at any point. At least I don't recall any discussion about this on the mailing list. But perhaps I missed it? Previously we had regular merges of minor dependencies every week. Now we have had no merges of dependencies since May. I don't think this makes sense - I'd much rather merge a few every week than block everything for months. |
|
@ptuomola Wasn't measured, it was mostly just too much PRs at a certain period (maybe back in April) for me and @vidakovic. Frankly speaking yeah, dependencies-wise we're a bit behind but it's not something we cannot easily fix, we just need to sort out the failures. The thing is, as I said a couple of dependency upgrade PRs would fail anyway (which are making this PR fail too) and those would hang there for a long time. I'd rather force ourselves to take a leap of faith and invest some time into figuring out why these things fail. As soon as we do that, we have a green light for the future PRs too. |
|
Well that's exactly my point: it was much easier to find out a) which things failed and b) why they failed, when the dependency upgrades were presented one by one rather than as one mega-PR. This also allowed splitting up the work - i.e. different people were looking at fixing different dependency upgrades, rather than everyone trying to guess who is (or if anyone is) working on fixing a combined mega-PR. Having said that, if you and @vidakovic are taking care of this from now on, then it's of course up to you to configure the workflows in a way that suits you. Personally I would have preferred a bit of a discussion about this first. |
Right, we probably should've brought it to the mailing list, our mistake.
Right, I don't think there's a "right" way to do this, it's rather what's suiting people better. I know for a fact that when the individual PRs came in, it was horror for me to manage. I've got so much spam I was about to turn on fineract notifications completely which makes really hard to track other changes going in. But that's just me. |
|
Just my 2 cents here: going forward the whole lib upgrade stuff won't be that "spontaneous" anymore... up until now we "only" had spring and spring boot (mainly)... with upcoming releases more spring frameworks (well, at least one) will be added to the mix and those all need to work together. They have a common release train, but usually that's a bit behind the specific releases of the frameworks. Just to say that upgrades will be probably a bit more conservative. |
renovate-bot
force-pushed
the
renovate/all-minor-patch
branch
from
c001f7b
to
310c807
Compare
Well even until now - I think we were trying to get as many of the dependencies from the Spring BOMs as possible. But unfortunately there were a number of reasons why this was not possible for some dependencies. Anyway - will leave the dependencies for you guys @galovics and @vidakovic to manage going forwards. Thanks. |
renovate-bot
force-pushed
the
renovate/all-minor-patch
branch
from
310c807
to
53c8f18
Compare
|
I prefer the approach where individual PRs are opened for every new release. Putting them all together like this increases tech debt because for one dependency upgrade failure..the PR has to wait for someone to fix all issues before merging. I wish we could have the previous approach. |
renovate-bot
force-pushed
the
renovate/all-minor-patch
branch
3 times, most recently
from
e4b17f0
to
1d31469
Compare
renovate-bot
force-pushed
the
renovate/all-minor-patch
branch
from
1d31469
to
15f9986
Compare
This PR contains the following updates:
14.2->14.42.13.1->2.14.010.2->10.3.142.3.5->42.4.02.7.5->2.7.61.5.1.Final->1.5.2.Final1.5.1.Final->1.5.2.Final4.10.0->4.12.02.2.0->2.2.12.2.0->2.2.12.2.0->2.2.11.6.0->1.6.11.6.8->1.6.91.6.8->1.6.91.6.8->1.6.91.6.8->1.6.91.6.8->1.6.91.10.5->1.10.76.1.0.202203080745-r->6.2.0.202206071550-r6.1.0.202203080745-r->6.2.0.202206071550-r4.9.3->4.10.04.9.3->4.10.04.9.3->4.10.04.9.3->4.10.04.9.3->4.10.01.2.0.RC6->1.2.00.50->0.524.7.0->4.7.14.8.146->4.8.1472.0.5->2.0.65.0.6->5.0.92.4.0->2.4.13.3->3.4.0.25131.12.213->1.12.2533.2.2->3.2.31.3.27->1.3.282.2.0->2.2.12.6.7->2.7.16.0.0->6.0.16.5.2->6.8.02.35->2.364.5.1->4.6.14.1.76.Final->4.1.78.Final7.3.4->7.4.12.13.2.1->2.13.31.6.21->1.7.02.6.7->2.7.15.3.19->5.3.219.0.62->9.0.641.0.11.RELEASE->1.0.12.RELEASERelease Notes
google/error-prone
v2.14.0New checkers:
BanJNDIEmptyTopLevelDeclarationErroneousBitwiseExpressionFuzzyEqualsShouldNotBeUsedInEqualsMethodInterruptionNullableOnContainingClassFixed issues: #3110, #3193
Full Changelog: google/error-prone@v2.13.1...v2.14.0
pgjdbc/pgjdbc
v42.4.0Changed
startup parameters in a transaction (default=false like 42.2.x) fixes Issue #2425
pgbouncer cannot deal with transactions in statement pooling mode PR #2425
Fixed
PR #2525, Issue #1311
Regression since 42.2.13. PR #2531, issue #2527
v42.3.6Changed
Added
Fixed
mariadb-corporation/mariadb-connector-j
v2.7.6Compare Source
2.7.6 (Jun 2022)
Full Changelog
mapstruct/mapstruct
v1.5.2.FinalCompare Source
Enhancements
Bugs
SubclassExhaustiveStrategy.RUNTIME_EXCEPTIONoption does not work if the superclass has a non-empty constructor #2891Build
liquibase/liquibase
v4.12.0Breaking Changes
Support for Snowflake database has been moved from the external extension liquibase-snowflake into the main Liquibase artifact. If you are using the snowflake extension, remove it from your
libdirectory or however you are including it in your project. If you are using the Docker image, thesnowflakedocker label will no longer be updated so you need to update your reference to eitherlatestor the version tag you prefer. For CLI users, the Snowflake driver also ships out of the box and so you should remove that from thelibdirectory as well https://github.com/liquibase/liquibase/pull/2841Enhancements
The Quality Checks commands have moved from limited availability in Liquibase Community to complete unlimited access only in Liquibase Pro. If you were using the community version, which was limited to five checks, you can test out the unlimited version with a free Liquibase Pro trial.
* make all QCs work only for Pro users (Pro PR 496) (DAT-10098)
${...}string that doesn't correspond to a set changelog property. The default continues to be "preserve" which leaves it as-is. But other possible values are ERROR or EMPTY which will either stop execution with an error or replace it with an empty string. By @dwieland in https://github.com/liquibase/liquibase/pull/2656http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.12.xsdtype XSDs references, you can now also usehttp://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-latest.xsdinstead. By using "latest", Liquibase will use the bundled XSD for it's version. The uploaded "latest" XSD will always be the most recent Liquibase release, so note how they can be different and locally cached IDE versions may be different yet. By @nvoxland in https://github.com/liquibase/liquibase/pull/2886Fixes
Updates
Security Updates
JDBC Driver and Third-Party Library Updates
OWASP Dependency Check: Reported Vulnerabilities
New Contributors
Full Changelog: liquibase/liquibase@v4.11.0...v4.12.0
Get Certified
Learn all the Liquibase fundamentals from free online courses by Liquibase experts and see how to apply them in the real world at https://learn.liquibase.com/.
Read the Documentation
Please check out and contribute to the continually improving docs, now at https://docs.liquibase.com/.
Meet the Community
Our community has built a lot. From extensions to integrations, you’ve helped make Liquibase the amazing open sour
Configuration
📅 Schedule: Branch creation - "before 3am on Monday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate. View repository job log here.