Closed Uzlopak closed 4 months ago
I'm not sure why we should add this here
Is it because it's not used often?
Just curious
It's just used for one module. It should stay in that repo.
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.
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 https://github.com/fastify/workflows/pull/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:
Benefits:
So, in summary, I believe we should merge this and #113, or remove the other workflows from this repo as well...
I would not have this here, but in the elasticsewrch repo
Please see the arguments and reasoning at https://github.com/fastify/workflows/pull/114#issuecomment-2067776753
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 https://github.com/fastify/workflows/pull/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
Checklist
npm run test
andnpm run benchmark