Use case diagram where actions are going through a third party system

Question

I am creating a system which makes static analysis on code when a commit to GitHub is made, the results are then showed as a GitHub review.
My problem is, this means that the developer (actor) will not engage with my system, as it is actually GitHub that does this. The developer (actor) is using GitHub and will see the result from my system in GitHub, hence they are never actually using my system directly.
I feel like the diagram below doesn't really capture this that well.

I then created another diagram, where the developer (actor) communicates with GitHub (actor) and GitHub then communicates with my system.
However this also seems wrong to be, but still better than before. One of my big problems with this is that GitHub is on the left side, however GitHub is kinda a primary actor, so it also makes sense. I have never seen any examples of use case diagrams doing this, is this actually valid and more importantly does it makes sense?

Side question: The CTO (actor) has a use case saying:

As a CTO, I want the tool to not save the code on the server running it, so that I won’t have to worry about our code being leaked.

For me this sounds like a valid use case, but when putting it into a use case diagram it feels off, as this is not really an action, it is more of a requirement. Should this just be part of like a functional requirement?

Edit: So I tried improving it based on the recommendations from you guys.
I ended up removing a lot of use cases, as they were more non-functional or functional requirements. Then I wanted to make the change to show that the tool is running remotely when a commit is pushed, not sure if I did that correctly.

Answer 1

One of my big problems with this is that GitHub is on the left side, however GitHub is kinda a primary actor, so it also makes sense. I have never seen any examples of use case diagrams doing this, is this actually valid and more importantly does it makes sense?

Nowhere is it defined that a primary actor must be a human. If, as far as your system can tell, Github is autonomously deciding to invoke your service, then Github is definitely a primary actor. It might then make sense to see the Developer as a secondary user of that use case.

Another way of looking at it might be that the Developer can run the tool locally on uncommitted code or remotely on a commit. In that case, the Developer would be the primary actor on the use cases and the use case for running on a commit would start with the action that the user commits/pushes to a repository (and with the precondition that the repository is configured to run the tool on commit/push actions). Depending on the audience, you then explain or gloss over that the repository is not actually part of the system, but included in the use case step to make it clear when/how the system is invoked.

Side question: The CTO (actor) has a use case saying:

As a CTO, I want the tool to not save the code on the server running it, so that I won’t have to worry about our code being leaked.

For me this sounds like a valid use case, but when putting it into a use case diagram it feels off, as this is not really an action, it is more of a requirement. Should this just be part of like a functional requirement?

It is a valid "user story", but it is not a valid use-case. It is not an interaction between an actor and the system and therefor it is not a use case.

Even as a user story, it is a bit problematic, because it is not a functional requirement that you can implement once and then mark it as done. It is actually a non-functional requirement that should be kept in mind continuously during the development of the system.