ci(ws): run client generator on frontend PR check

[caponetto]

related: #499

This PR updates the CI pipeline for the frontend workspace to fail if there are uncommitted changes in generated code. This helps ensure that all generated files are properly committed and that CI reflects the actual state of the codebase.

Note: The fetch-depth: 0 argument is required to fetch the full Git history, allowing us to retrieve the specific Swagger version referenced by the commit hash in the swagger.version file.

[paulovmr]

/ok-to-test

[paulovmr]

/lgtm

[paulovmr]

Hi @thesuperzapper , although this is related to the frontend, because of the directory of the changed file, we might need your approval as well, if you could take a look please. Thanks!

[thesuperzapper]

@caponetto @paulovmr @harshad16 @andyatmiami we were discussing this in the meeting today, and came to the concusion that this is probably the best of the options (that is, allowing the frontend devs to explicitly choose which commit of the swagger json to generate from).

This was because:

1. it ensures that frontend devs don't change the generated files (ci now runs generate and checks for diff)
2. if we always ran the generator based on the HEAD of the branch, it would result in the next frontend PR having to run the generator (and bring in a lot of diff) to have its PR checks pass

The main question is when and who should be updating the generator commit:

• OPTION 1: which ever frontend PR needs the new API feature first (or encounters a bug/breaking change)
• OPTION 2: some regular job which tries to get HEAD to use the latest commit that changed the swagger JSON

Either way, this is an improvement from the current situation, so we can merge.

/lgtm
/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: thesuperzapper

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [thesuperzapper]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment