[avodonosov]

Why isn't the failing tests the problem of the person who changed that line?

What you describe is very strange.

If someone changes a shared module, and some tests fail in result, his changes simply should not be merged.

> you will get a ticket to understand what has changed, make changes and fire up every tests

Do you fire tests manually?

[loukrazy]

If you make changes to a large shared module, is it your responsibility to chase down each and every usage of it? For example if you are upgrading a dependency due to a somewhat breaking security issue such as Jackson 2.8->2.12

[jsolson]

At Google it mostly _is_ your responsibility to do that, yes.

There is substantial tooling assistance to assist with this, and it's common to make changes by adding new functionality, writing an automated transform to shift usage from old to new, sharding out the reviews to the suitable OWNERS, and finally removing the old functionality.

Very heavily used common code tends to be owned by teams that are used to this burden. That said, it does complicate upgrades to third party components.

[avodonosov]

You do not chase down, the buld system detects all affected modules and runs their tests. That's the advantage of monorepo - contineous integration that includes all dependent modules.

[barrkel]

It's also a disadvantage, to be clear. Tests take longer to run when you need to rebuild your database and not just your own code. There's no easy way to put something in maintenance mode and only take changes for bug fixes, because maintaining forks is not a significant thing. Thus downstream dependencies must pay not just for bug fixes but also for feature improvements, deprecations etc.

It works well enough if everything is making money and is being actively developed.

[andreareina]

IIRC that's how it works for internal APIs in the linux kernel.

[joshuamorton]

Tldr yes it's the responsibility of the person doing the update to inform and usually fix the majority of users. There's often a long tail though.