You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hopefully fix those dreaded 😕 reactions by GitForWindowsHelper (#197)
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...
0 commit comments