Extract common Github action steps as a separate Repository and reuse them

[yeikel]

When multiple projects need to use the same configuration, it is beneficial to create a common workflow and share it among other projects. As we have many repos, there are some steps that are duplicated that we could create and share instead of maintaining them individually.

For example https://github.com/FasterXML/jackson-bom/blob/2.15/.github/workflows/main.yml#L40-L49 (there are probably more)

As we currently have many repos with duplicated configurations, I had to create the same pull requests across our projects to have consistency

You can see this technique in action here: https://github.com/openrewrite/rewrite/blob/main/.github/workflows/ci.yml#L20-L22

[pjfanning]

If the Jackson team were super interested in having the latest versions of everything, we could just configure dependabot to create PRs automatically. I, personally, don't see the point in these PRs. My opinion is that you should have suggested why the plugin needs to be upgraded - in an issue - before raising all these PRs.

[yeikel]

Thank you for your input. Here are my thoughts:

1. Dependabot doesn't support embedded dependencies like this example as far as I know

2. It is always a good idea to use the latest versions. It usually simplifies the upgrade paths in the future(i.e., Maven 4)

3. We have the same plugin declaration across multiple repos with different versions. That usually never helps

As a side note, the main point of this discussion is to discuss the possibility of extracting the common workflow steps to a single location whenever possible. The concrete plugin was just an example to prove that we have the same declaration across many different places

[pjfanning]

How about apache/creadur-rat#71 ? - this is an example of dependabot creating a PR to upgrade a maven plugin

I would vote to use dependabot any day over having random PRs pop up where users upgrade jars/plugins/github-actions just for the sake of it. If someone came along and raised an issue and provided a reasonable justification other than upgrading for the sake of it, then that's potentially worth looking at.

From experience, you can quickly end up with jar/plugin/github-action upgrade PRs dominating the commits and often for little benefit.

[yeikel]

The PR you listed is upgrading a plugin in the pom file, the example PR that I shared is from a step within the Github action. As far as I know, the dependabot support for Github actions limits exclusively to the actions themselves. We could, however, declare the plugin in our pom instead and then dependabot would work there

I agree about automating as much as possible. Dependabot is the way, but as mentioned it does not work with the existing setup

[cowtowncoder]

I'd be +1 for such a repo, but don't think I have time to work on actively figuring this out. But if anyone wants to try it, I could easily -- for example -- create a repo under FasterXML and give necessary rights, and then when there's a PoC, help convert existing workflows to use new pieces.

If shareable components could then use "floating" label/version (that is, reference which tracks new versions of component), they could embed versions of actions they depend on, reducing need to update just one place (or small number).
That'd be win. Dependabot might be useful then, or maybe not; either way upgrades would be simpler indeed.

[yeikel]

@cowtowncoder Feel free to create a repo and give me permission to write to it. I'll draft an initial version over the next couple of weeks (my capacity is also limited :)

[cowtowncoder]

Here you go @yeikel : https://github.com/FasterXML/jackson-gh-actions