Ever since GitHub changed their REST API so that the date range in their `search` endpoint didn't work as expected by GitForWindowsHelper's logic anymore, I've been struggling to find a work around or fix for this. I thought that I had at at long last figured out the correct syntax in 77cd499 (after none of 1ff8966, a4e3ff8, 2627695 and 2e91f07 did the job) but today we experienced another of those dreaded :confused: reactions in git-for-windows/git#6097 (comment): <img width="288" height="100" alt="image" src="https://github.com/user-attachments/assets/da852ab2-1441-4894-b542-cbaef240ff2a" /> The response for that webhook is simply empty, because it timed out before responding, unfortunately: <img width="1046" height="217" alt="image" src="https://github.com/user-attachments/assets/853056fb-5b47-4dc5-bfb5-ba1e028b3da6" /> I actually had started looking into this a little over a week ago (using the embargoed org to perform my experiments because I did not want to mess around with the `main` branch of `git-for-windows-automation` in production). And it _looks_ as if the `date:` header returned in that unhelpful 204 that is the (otherwise empty) response when [creating a workflow dispatch event](https://docs.github.com/en/rest/actions/workflows?apiVersion=2022-11-28#create-a-workflow-dispatch-event) can be either identical to, or even come _after_, the date reported as the `created_at` attribute of the corresponding workflow run. To be sure, the root cause behind all of these troubles is that for all those years, there was a really annoying gap in GitHub's REST API. It should be so easy to obtain the corresponding workflow run when triggering one via a `workflow_dispatch`: Literally everybody who triggers a workflow run programmatically needs to obtain a reference to the workflow run that was triggered by it. That's necessary. This is required. However, there is no reliable way. And what we did was just to work around that. By polling for workflow runs that were created _after_ we asked for one to be triggered. And even those workarounds were broken, so the entire saga is _quite_ frustrating. The good news: After years of frustration, it seems that some new wind was blown into GitHub Actions, and they fixed that! See https://github.blog/changelog/2026-02-19-workflow-dispatch-api-now-returns-run-ids/ for full details. Unfortunately, this is of course not enough. Apparently yet another external change prevented me from using the Role-Based Access Control (RBAC) method to deploy the Azure Function to the embargoed org, which was _already_ a work-around from back from April 2024, when I worked on creating artifacts for an embargoed Git for Windows release. Of course, I did expect this to deploy without problems, after I verified in my experiments that the clock skew patch works around the new issues in a local run-through. So I basically merged those changes from the embargoed builds to be able to deploy. But the deployment failed, RBAC no longer works, and I documented that in the follow-up commit: Luckily, for completely unrelated reasons, elsewhere (in GitGitGadget), I had already developed patches to deploy an Azure Function via OpenID Connect. So I ported those changes to the Git for Windows helper app. Unfortunately this still was not enough. I had to also allow for overriding not only the `activeOrg` but also the `activeBot`, because in the non-embargoed builds (i.e. in `git-for-windows/git-for-windows-automation`'s `main` branch), we now verify that the sender is the expected bot. The end result is unfortunately a complex PR that tries to do something simple, but for various reasons needs to be a lot more complex just so that we can actually deploy the result...

[New innosetup version] is-6_7_1 #6097

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions