Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update tag-git comment in cascading runs; Follow up #49

Conversation

dscho
Copy link
Member

@dscho dscho commented Nov 14, 2023

In #47 I tried to teach GitForWindowsHelper to find the PR comment containing /git-artifacts when the tag-git check run finished that was triggered by that slash command. However, it did not work, despite the webhook being delivered with status 200 and the response body being:

The git-artifacts-x86_64 workflow run was started.
The git-artifacts-i686 workflow run was started.

I do not really know why it failed, but when I tried to run the code locally (commenting out the part that would have triggered another pair of git-artifacts runs), it didn't work for me either, due to expire time issues ("too far in the future") and due to too-strict matching (sometimes the fragment in the search result ended in a newline character, sometimes it did not).

This PR is designed to help with both issues, so that hopefully the v2.43.0 (final) PR will see the /git-artifacts comment being updated as intended.

At least when I ran the code locally with these modifications, the /git-artifacts comment was updated as I wanted, if somewhat belatedly.

…bust

In my tests, it seems that the trailing newline may be shown when
searching without any token, and trimmed when searching with token.

That makes no sense, but let's guard against this condition anyway.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In my tests, sometimes even though the 10 minutes maximum expire time
worked when searching for the comment, it still was possible for the
subsequent request (appending to the comment) to fail with:

	'Expiration time' claim ('exp') is too far in the future

Let's work around that by avoiding the full 10 minutes expiry and going
for 9 instead.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
@dscho dscho requested a review from rimrul November 14, 2023 21:17
@dscho dscho self-assigned this Nov 14, 2023
// JWT expiration time (10 minute maximum)
exp: now + (10 * 60),
// JWT expiration time (10 minute maximum, use 9 to allow for clock drift)
exp: now + (9 * 60),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the 10 minute maximum is supposed to be 10 minutes from iat, so with that being offset 60 seconds into the past, exp being 9 minutes in the future would make sense.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the same thought, but why did it seem to work so far, then? It's a puzzle.

@dscho dscho merged commit 11796c6 into git-for-windows:main Nov 15, 2023
1 check passed
@dscho dscho deleted the update-tag-git-comment-in-cascading-runs-follow-up branch November 15, 2023 06:06
@dscho
Copy link
Member Author

dscho commented Nov 20, 2023

It worked!!! No manual interaction necessary, apparently this PR made the logic robust enough. Yay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants