add elasticsearch ci

[Uzlopak]

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[gurgunday]

lgtm

[mcollina]

I'm not sure why we should add this here

[gurgunday]

Is it because it's not used often?

Just curious

[mcollina]

It's just used for one module. It should stay in that repo.

[Uzlopak]

Its just an offer. Probably would remove that github action in the corresponding repo and replace it with the service entry in the github workflow.

[gurgunday]

It's just used for one module. It should stay in that repo.

This is also the case with the MongoDB, Postgres, and MySQL workflows

Now, following the same logic, it makes sense to move them to the repos where they're used; however, if we merge #124 and centralize most library CIs too, it could be more efficient in the long term to take it one step further and centralize everything as much as possible

Right now, there is no consistency to when we put a workflow here or to a dedicated repo

So I propose that we:

• centralize all workflows that follow this generic structure and add one simple thing/feature to it
• only create a dedicated workflow in a repo if it requires significant modifications to the generic workflow

Benefits:

• When creating a new repo that will use kafka, mysql, etc., maintainers will know where to look first before thinking about creating a custom workflow
• When the time comes to modify the generic workflow, it will be easier to also update its flavors

So, in summary, I believe we should merge this and #113, or remove the other workflows from this repo as well...

[mcollina]

I would not have this here, but in the elasticsewrch repo

[gurgunday]

Please see the arguments and reasoning at #114 (comment)

In this repo, we already have the MongoDB, MySQL, and PostgreSQL workflows that are only used once — in fastify-mongodb, fastify-mysql, and fastify-posgres respectively, we should remove those from here as well then

But I'm arguing that it's actually easier to manage this way, for instance in #116 all it took was one PR to add BlueOak support to the main workflow and all its flavors, this is just another flavor of that main workflow

If a repo really requires a custom workflow radically different from the main workflow, then I'm not against putting it in its repo, but in general things will become easier to manage for these simple one-feature workflows in my opinion

[mcollina]

lgtm