Add CI feature to trigger jackson-databind re-build on jackson-core deploy

[cowtowncoder]

Describe your Issue

Currently our CI does not have means to trigger re-build of dependencies so that ideally we would for example do:

1. change to jackson-core default branch triggers CI, publishes SNAPSHOT version
2. this triggers re-build of jackson-databind in same branch (default, naming convention), to build, verify and publishes SNAPSHOT version
3. this triggers builds of jackson-dataformat-xxx and other (selected) dependencies

There is a way to do this with something (remote dispatch?); but as the first proof-of-concept, let's implement (2). And although it'd be nice to trigger this for all active branches, let's start with just default branch (currently 2.18). If and when this is implemented we can extend both across different repos (ideally jackson-modules-base, jackson-datatype-collections, all format modules), based on known problem cases.

The main benefit here is that we will find more quickly if there are regressions: usually due to jackson-databind changes, but sometimes jackson-core, breaking format or datatype modules.

Note: alternative that we could also consider would be to do the reverse: new repo that simply builds content from other repos, explicitly; but it'd need to run on Cron, like daily. That is a possibility too. But for most critical dependencies triggering this on push to default would be most timely and reliable way to catch problem.

[JooHyukKim]

This would be super helpful! Especially for dependency branching out of databind

[cowtowncoder]

Note: on re-build we have basically 2 main possibilities:

1. Trigger full, regular "build and deploy" matrix, including deploy
2. Trigger just limited ./mvwn verify to run (unit) test suite

depending on how easy (1) is to achieve. And ultimately maybe cost, don't want to run out of quota.

Github CI action to use is, I think, this:

https://github.com/marketplace/actions/repository-dispatch

which is used at work successfully.

[cowtowncoder]

@JooHyukKim yes, exactly! core/databind changes can break formats/datatypes.

[cowtowncoder]

Implemented so that

1. When jackson-core is successfully built, on push to default branch (2.18 currently), rebuild of jackson-databind is triggered.
2. When jackson-databind is successfully built -- either on push to default branch, or due to trigger from (1), a bunch of rebuilds is triggered
3. ... that is, all 3 dataformat repos (binary, text, xml), jackson-module-base, 2 datatypes (collections, misc), are rebuilt

It would be possible to extend this further if it feels reasonable, by both:

1. Adding more dependencies (maybe Scala and Kotlin modules at least?)
2. Could try adding this for other branches: mostly, master (3.0), although things can get complicated so not sure as branch would need to be passed

The goal here is to more quickly catch possible compatibility issues across components: will not help catch them for PRs (which is somewhat complex problem if that was to be tackled), but will at least let us know if something breaks temporarily. This can cause noisier failures during some updates but should help find issues that formerly may have taken days or even weeks to uncover in some cases.

[cowtowncoder]

/cc @JooHyukKim @pjfanning @yawkat @k163377 @yihtserns

Technically this is done using repository-dispatch plugin; jackson-databind/.github/workflows shows how (if anyone interested):

1. main.yaml is the existing Build-and-Publish, and on successful completion, calls workflow trigger_dep_builds.yml
2. dep_build.yml is workflow that receives dispatch from jackson-core (event jackson-core-pushed), also calls trigger_dep_builds.yml
3. trigger_dep_builds.yml sends event dispatch downstream (event jackson-databind-pushed)

Anyway: this is something I had thought about doing for long time and finally decided to figure it out.

LMK what you think.

[JooHyukKim]

+1 for adding Scala and Kotlin module for the high usage. I can work on it later today if they're not added

[cowtowncoder]

Sounds good @JooHyukKim : I think I'll add jackson-module-kotlin as it should be easier as it uses Maven. Scale module builds using sbt which I am not familiar with so if you want to have a look (or @pjfanning as he knows the build part) that'd be great!

[pjfanning]

I created https://github.com/FasterXML/jackson-module-scala/blob/2.18/.github/workflows/upstream-dispatch.yml as a temp solution.

I use a build tool to generate the CI scripts but I don't think that tool supports dispatch events.

[cowtowncoder]

That looks correct to be @pjfanning wrt receiving repository-dispatch created event.

[cowtowncoder]

Ok, Kotlin and Scala module (thanks @pjfanning !) are both added.