feat: Add taplo CI

[aidan46]

Description

taplo lint and taplo format, in that order, have been add on push and pull request into any branch. Part of #3

[jmg-duarte]

LGTM, but left an idea to consider

[serg-temchenko]

Looks good, but some points should be discussed. Thank you!

[jmg-duarte]

Actually, I was thinking of having one workflow for the CI, like ci.yaml, to avoid running multiple runners in parallel.

This can be controlled using concurrency. Furthermore, having one workflow doesn't stop runners from running in parallel. If there are no dependencies between jobs, the runners will execute in parallel (source). For example, in this pipeline I wrote in my last job, the build actions (make-*) all ran in parallel, though they are contained in the same workflow.
If you really want sequential, you need to use needs:<last-job> in every job.

Additionally, including all preparation steps such as checking out to the branch, installing extra dependencies, caches, and sharing the context between workflows would make it unnecessarily complex and introduce a lot of duplication that needs to be maintained in multiple places.

It doesn't work this way for the preparation steps and dependencies. The "work unit" in GitHub Actions is the job, which gets picked up by runners, whether they are in the same workflow or not it doesn't matter, you'll still need to always set them up with extra dependencies unless you're running self-hosted runners.

I agree with the context and cache point though, especially because GitHub doesn't have a good way to orchestrate multiple workflows, but keep in mind that a big CI pipeline may work against us in terms of time spent. Regardless, we can always change it as the project evolves.

[jmg-duarte]

LGTM

[aidan46]

I set the target branch to feat/3/CI-setup to merge all the CI into before merging main. LMK if you guys prefer that or just merge straight to main.

[jmg-duarte]

I set the target branch to feat/3/CI-setup to merge all the CI into before merging main. LMK if you guys prefer that or just merge straight to main.

This makes sense to me because there's a single tracking issue, once the other branch gets merged that works out.

But it will depend on how linear you guys want the history to be. Personally, I prefer linear histories (to the point that I prefer rebase over merge for my projects)

[th7nder]

I set the target branch to feat/3/CI-setup to merge all the CI into before merging main. LMK if you guys prefer that or just merge straight to main.

I was going through the GitFlow and didn't see any recommendations for this at a glance (we use this model apparently).
If a change is working, is kinda self-contained and thoroughly tested I don't see a reason for it not to be merged into develop.
It can be useful for other people, who create their own branches off-of develop.

[serg-temchenko]

Waiting for PR #5 to be merged first so that we have a clean diff.

The base branch was changed.