Is it possible to request a git log from the remote server without being "in" the git repo locally? For example, I am a build server and I received a web hook from GitHub, but I want to check the last log before deciding to clone the repo, scheduling an agent, and continuing. So rather than having to create a repo locally, cd into it, set a remote origin, and then request the log, I'd rather just request the log immediately since I know the location of the remote repo from the hook.
Something to the effect of git log -1 --repo https://foobar/myrepo.git. Is there something like this or another way I could check that commit summary before cloning?
Edit:
The actual context is that we're using Conventional Commits which supports a number of different 'types' of commits, and we use them to do some pretty useful things like automatically version the build. One of the things we're doing now is attempting abort the build process if the type is a "no build" type of commit such as "docs" (at least until we automate the docs build, then it would just be a selective stage). We have something coming up where devs are going to be updating docs a lot and the way one of our other system ingests these docs requires it be in master. So during this phase, we don't want it to start thrashing the build server. Using conventional commits is almost a text book use case for this.
So we looked at ways to do this, and we could just put it in the build script to check if it's a docs type and if so, just abort the build (not fail or succeed because that would corrupt the metrics). And this should probably work fine, however the draw back is that Jenkins will have to pull the repo down first in order to check the previous log for the type, and before that, it would actually have to schedule an agent to pick up the build which means the build server is still gonna get thrashed.
So the current idea we're investigating is if the master node, when the hook comes in, maybe it can just do a lightweight operation like grabbing the last log from remote before pulling the repo or scheduling the agent and then deciding whether or not to continue or ignore. In fact, the git plugin in the job configuration ALMOST solves this in that it supports the ability to filter events as the web hooks come in except it only works for polling, there is no config for web hooks. Dang.
The other idea was to see if GitHub had the ability to add some sort of condition or middleware that could decide when it should fire a specific web hook (i.e. the one that notifies Jenkins). I don't think that's possible, but in that same vein, it's possible we could just rig something up where we use GitHub actions to fire the "hook" (basically just a script that makes an HTTP call, where we could add in some more logic in between) instead of using the native hooks but that sounds pretty kludgy and like it wouldn't scale well with hundreds of projects.