RHCLOUD-33054 - Sync protos to java client

[lennysgarage]

PR Template:

Describe your changes

Wanted to take some time to address a feature that we've wanted to implement in some way for a while. This PR adds an action that upon changes being made to proto files they are automatically synced over to relations-java-client with an open PR for review.

• Action runs upon changes to the api/ directory
• Copies proto files from relations-api into relations-java-client and opens a PR

I have tested this out in my own forks with the action running here: https://github.com/lennysgarage/relations-api/actions/runs/10580215481/job/29314509563 with it opening a PR in my relations-java-client fork here: lennysgarage/relations-client-java#4

Still required:

• a PAT, a personal access token with repo scope is required for creating the PR in another repo.

Ticket reference (if applicable)

Fixes # RHCLOUD-33054

• May also cover https://issues.redhat.com/browse/RHCLOUD-32486
• • If we copy proto files over from the source of truth (this repo) we don't need to fetch them from the buf schema registry.

Checklist

• Are the agreed upon acceptance criteria fulfilled?

• Was the 4-eye-principle applied? (async PR review, pairing, ensembling)

• Do your changes have passing automated tests and sufficient observability?

• Are the work steps you introduced repeatable by others, either through automation or documentation?

  • If automation is possible but not done due to other constraints, a ticket to the tech debt sprint is added
  • An SOP (Standard Operating Procedure) was created

• The Changes were automatically built, tested, and - if needed, behind a feature flag - deployed to our production environment. (Please check this when the new deployment is done and you could verify it.)

• Are the agreed upon coding/architectural practices applied?

• Are security needs fullfilled? (e.g. no internal URL)

• Is the corresponding Ticket in the right state? (should be on "review" now, put to done when this change made it to production)

• For changes to the public API / code dependencies: Was the whole team (or a sufficient amount of ppl) able to review?

[app-sre-bot]

Can one of the admins verify this patch?

[merlante]

Thanks for this. We definitely need a solution to this problem.

Some questions/thoughts:

1. What happens when a proto is updated and updated again before the PR is merged? Is a second PR created? It would be nice just to have one PR.
2. I wonder if it's the right approach to create PRs from the relations-api side -- meaning the relations-api repo cares about the structure of the client repo -- or whether we should have client repos "listening" for changes and doing their own thing?
3. Along the same lines, do we end up doing the same thing for go and python?
4. Is there a chance that a failure to create the PR will fail the push? (I'm guessing not, but worth asking the question.)

Anyway, even if this is not the perfect solution, we can improve it later. At the moment, we don't have any visibility on when the proto changes in the client repo. Might be easier to discuss than type. :)

[lennysgarage]

@merlante Appreciate the feedback, I tried to address your questions and I'm down to discuss some more together.

1. At the moment, there's no updating the first PR or even creating a second one. It will currently fail if another is already open. Definitely a point to fix.
2. I thought about the other way of doing things, we could in theory have a cronjob type action on the client side that watches for changes and opens a PR in its own repo instead of getting the source of truth to open in each client. Would also allow for better usage for point 3 where each client can take care of updating themselves.
3. It might make sense to have a watch event in each client that can watch for changes and update whenever the relations-api changes. Downside is delay to getting changes into the clients, but shouldn't be too long.
4. Related to feat: adding spicedb setup with docker and with kind #1 there is a failure if a PR is already open, the changes don't get added to the open PR. Moving to client side opening PRs would also need to address this.

Based on your suggestions, I think it makes more sense to setup a watch action in each client that can clone the relations-api see if there are any changes and open the PR in its own repo itself. Would also simplify the process as it shouldn't need a PAT to get working

[lennysgarage]

Closing in favour of project-kessel/relations-client-java#26
Running the action directly on the client side.