Workflow consistency and refactor

[cprecioso]

• Resolves Improve workflow triggers #3204
• Resolves Move away from paths triggers in Github actions #3219
• Resolves Ensure rolling updates to example apps #3206

In this PR we do multiple things at once:

• Renames all the workflows in the same way "{workflow kind}-{feature}-{action}.yaml" so that we can quickly find what we need (workflow kind is one of ci, automation, or release).
• For all the workflows related to CI, we take away all of their push and pull_request triggers, and paths filters.
• We have a main ci.yaml workflow that calls all the others. This also simplifies the release.yaml workflow since it can just call ci before doing its stuff.
• Updates actions/checkout and actions/setup-node to latest version (no breaking changes)
• Removes the actions/checkout workaround that use the PR head commit instead of the PR merge commit
  • This was a "workaround" in quotes because it wasn't working around a bug but the stated, expected GitHub actions behaviour.
  • Original motivation was to avoid the situation were main was broken, but the PR was based on a previous non-broken main, so you wouldn't readily know where the breakage was coming from.
  • Now that we have the same tests on main and PR, this won't happen anymore
  • For the I in CI, we need to be checking how the new code behaves when merged with the current version, so it is more correct to test on the merge commit
  • Plus, GH will give us the cache for the current main, not the version of main the PR was based off. Testing on the merge commit means it is more probable that we can reuse the warmed cache.
• Adds WASP_TELEMETRY_DISABLE to workflows where we had forgot it

Result:
We run the exact same CI checks both in PRs and main, continuously (hey that's the C in CI!) We do so in the same consistent way, with easy-to-understand entry points.

Future improvement if we feel any pain:

• This PR doesn't add any new caching. We can do that if it becomes too long.
• We also don't mandate any ordering, so every workflow launches in parallel. We can change this if we want.
• We can build the wasp cli only once and use it everywhere we need it, for deduplication

[cloudflare-workers-and-pages]

Deploying wasp-docs-on-main with    Cloudflare Pages

Latest commit:	1bec412
Status:	✅  Deploy successful!
Preview URL:	https://b5db7b09.wasp-docs-on-main.pages.dev
Branch Preview URL:	https://cprecioso-consistent-workflo.wasp-docs-on-main.pages.dev

View logs

[FranjoMindek]

I like that we are consistent on .yml vs .yaml now.

If possible I would shorten the "Continuous Integration" to "CI" so we see time in this table.

Also at glance CI seems faster now, I presume due to workaround removal?

[FranjoMindek]

I thought we fixed this one already. Well good thing we do now.

[infomiho]

Went through the changes, looking good 👍

[sodic]

Looks great! Just two questions

[sodic]

Doesn't this talk about all tests, not just the CI?

[cprecioso]

I was thinking it talks about the tests regarding todoApp, no?

[sodic]

Oh, right, didn't see where we were at. IN that case, is ci-waspc-test the correct workflow to point it to (might be, just double checking)?

[cprecioso]

it is! that worflow is too big and does a lot of stuff

[cprecioso]

somebody braver than me might want to take a stab at it some time 😁

[FranjoMindek]

TodoApp renaming PR already moves TodoApp stuff into examples workflows.
Best thing is because the abstraction work well, it's just adding the examples/kitchen-sink name to the matrix.

[sodic]

Perfect