ci: CITGM github workflow

[Uzlopak]

I created a CITGM github workflow as a PoC. This one is to run the core plugins.

You could trigger the workflow by assigning the "citgm-core-plugins" label to a PR.

We could add community-plugins and maybe projects like platformatic in other github workflows.

We could also trigger it via workflow dispatch, if we want.

See following action run result:
https://github.com/Uzlopak/fastify/actions/runs/7323976506

This workflow could mean, that we should change our release process. Curerntly @mcollina is updating the version in package.json and directly committing it. With citgm workflows in place, it would make sense to create a PR for updating the version in the package.json, then trigger citgm workflows. If its green, we merge the PR etc..

Currently some of the cases with databases fail. We could check if we add a npm script to those to spawn a database docker container?! fixed

Some cases fail already, lol. My CITGM successfully detected incompatibilities... e.g. @fastify/throttle seems to be broken because we added detection of mixed callback and async await usage. fixed

Currently only node lts and ubuntu-latest is used. We should obviously discuss about using more node versions and add windows and macos. But as long the ubuntu and node lts tests are not green, and we did not agree on using this github workflow I would add them gradually after agreeing on using this approach.

Looking forward for your feedback ;).

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

[Uzlopak]

Need to merge following PRs to get the CITGM green (will be updated)

• fix: invalid hook function head fastify-throttle#12
• test: use t.error fastify-jwt#322
• fix: upgrade json-schema-to-ts to v3.0.0 fastify-type-provider-json-schema-to-ts#69
• Revert "chore(package): explicitly declare js module type" fastify-nextjs#902
• workaround: make types work with latest fastify fastify-funky#148

[Uzlopak]

@galvez
fastify-vite has no tests :/

[galvez]

It does, it's just not integrated yet — let me try and move that task up in my queue...

[Uzlopak]

I invested alot of time, but I could not find a proper solution for fastify-funky. So I propose a workaround.

@galvez I just commented out fastify-vite till it can run tests via npm t

If we merge the the remaining 3 PRs mentioned above, the citgm workflow would be green for ubuntu and node 20.
We could then use node 21 and node 18 and see if we detect more issues.

[Eomm]

Could we move it to https://github.com/fastify/fastify-citgm?

[Uzlopak]

@Eomm

The workflow seems to be very specific for this repository. tbh I dont see why we should move them into another repository.

E.g. if we modify ecosystem.md, we should add the plugin into this workflow in this repo and not somewhere else.

[Uzlopak]

I think it is ready for first critical review.

Maybe citgm-package.yml should be smarter and use a strategy matrix and accept comma separated inputs for os, node version and package. Then we could maybe avoid the 256 strategy limit.

But looking forward to your feedback.

[zekth]

I feel maintaining this at fastify repo level and plugin level can be a pain. Can't we standardize to use a docker-compose.yml file in repositories which need it? Like having a command stat docker-compose.yml && docker-compose up -d --wait (for example)

[metcoder95]

+1 on @zekth but I'm also over the fence about having docker-compose.yml as we move the maintenance to each library to match the CITGM flow of fastify.

If the plan is to just support core plugins for now, shall we consider maybe having a custom action in another repo to offload that maintenance somewhere?

In that way, we can also (maybe) empower the community to add their plugins to be tested (e.g. platformatic, opentelemetry/fastify just to name a few)

[zekth]

I think this should be handled at downstream repo. Maybe having a docker container in the repo executing the commands. Tho this might even be just a pre-test setup in fastify-postgres

[zekth]

i get your concerns about hitting the max strategies, however i don't think we should test X number of node versions / os. This should be handled at lib level and not in the fastify one IMO.

[mcollina]

I think we should land this first for all modules that require no databases, etc, and then figure out a solution for those.

[Uzlopak]

Is this to your likings?

[mcollina]

lgtm