Add CI action to autogenerate catalog client code

[mkenigs]

• Write a CI action that automates generating code on auto-opened PRs with spec updates. Likely push a commit to the PR with the updated Rust code
• Handle breaking changes in an auto-opened PR. A new JSON spec file should be committed, and a new client crate should be committed

[mkenigs]

I'm now wondering if it would make more sense to generate this on the server CI, because sometimes progenitor will generate something that doesn't compile. Might be worth compiling the generated code before merging a change to the spec

[ysndr]

Agree we should probably just have the server ci create a pr (just like dependabot)

• git switch -c ...
• update cli/catalog-api-v1/openapi.json
• cargo build --manifest-path ./cli/Cargo.toml -p catalog-api-v1
• git add cli/catalog-api-v1/openapi.json
• git add cli/catalog-api-v1/src
• git commit
• git push
• gh pr create --repo flox/flox --base main --title "build: bump catalog api spec"

[zmitchell]

Might be worth compiling the generated code before merging a change to the spec

Are you suggesting that we shouldn't merge catalog-server PRs with spec changes that progenitor can't compile?

[mkenigs]

Are you suggesting that we shouldn't merge catalog-server PRs with spec changes that progenitor can't compile?

Yes. I saw that a few times when we were first using it but haven't seen it since. If things are failing to compile very frequently I would rather block merges to catalog-server

[mkenigs]

From grooming: The api crate compiling should block api changes. Attempting to compile flox would be a nice to have, but it wouldn't be blocking