Generate clients CI create PR

[paddatrapper]

I'm not sure what we want here. Do we want a push to main on schema update or do we want it to push to a branch and open a PR against main for any changes?

The PR approach is easier to audit, but does add complexity in how those PRs are managed.

[jooola]

I would always push to the same branch over and over and open a PR if the branch is ahead of main.

We should be able to pill up many client regeneration in the same branch/PR.

[jooola]

Also, a few problems I see in the workflows:

• Don't cancel in progress workflows, as we want to make our life easy to track changes across repositories. Skipping a commit would mean squashing them together.
• Change the commit message and author details

      - name: Commit changes
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: "chore: update clients"
          commit_user_name: "github-actions[bot]"
          commit_user_email: "github-actions[bot]@users.noreply.github.com"

[paddatrapper]

The reason I configured cancel in progress is to prevent race-conditions - if there are two pipelines running concurrently there can be inconsistencies introduced between them in the following case:

1. commit 1 clones
2. commit 2 clones
3. commit 2 completes
4. commit 2 pushes
5. commit 1 completes
6. commit 1 pushes <-- Here there will a problem

[jooola]

To fix the issue you are describing we only need to set a concurrency group for the workflow.

Workflow will always be queued in the same order they are received (with the push event) so they should always run in the right order. To prevent the commit 2 workflow to push before the commit 1 workflow, using the concurrency group will put the commit 2 workflow in pending mode awaiting for the commit 1 workflow to finish.

So I think we can safely remove the cancel in progress key, but keep the concurrency group.

See https://docs.github.com/en/enterprise-cloud@latest/actions/using-jobs/using-concurrency