openssh: update to 9.3.P1

[gitforwindowshelper]

This closes git-for-windows/git#4348

[rimrul]

/deploy

The x86_64 and the i686 workflow runs were started.

[rimrul]

And that failed because we're passing a ref instead of a rev to the checkrun action.

[dscho]

Whoops. This is not good. The automation failed. I am on it. Or would I step on your toes @rimrul?

[dscho]

To be precise, I am talking about this error:

Error: Need to `get()` Check Run before calling `update()`
    at Object.state.update (D:\a\git-for-windows-automation\git-for-windows-automation\check-runs.js:189:26)
    at eval (eval at callAsyncFunction (D:\a\_actions\actions\github-script\v6\dist\index.js:15099:16), <anonymous>:24:68)
    at async main (D:\a\_actions\actions\github-script\v6\dist\index.js:15198:20)
Error: Unhandled error: Error: Need to `get()` Check Run before calling `update()`

[dscho]

Actually, the root cause seems to be here:

Error: Expected either 'rev' or 'conclusion' to be specified
    at eval (eval at callAsyncFunction (D:\a\_actions\actions\github-script\v6\dist\index.js:15099:16), <anonymous>:4:9)
    at callAsyncFunction (D:\a\_actions\actions\github-script\v6\dist\index.js:15100:12)
    at main (D:\a\_actions\actions\github-script\v6\dist\index.js:15198:26)

[rimrul]

No, it's fine. I think it's literally just failing because of the letter f instead of v in the parameter name for the action. We seem to already pass a commit SHA from the slash command code to the workflow.

[dscho]

No, it's fine. I think it's literally just failing because of the letter f instead of v in the parameter name for the action. We seem to already pass a commit SHA from the slash command code to the workflow.

Right. I think I renamed this in my release-git work...

[dscho]

Almost looking good. The only problem I see is the funny space:

[dscho]

The only problem I see is the funny space

I have a fix for that, and once the workflow run completed, will push an update to git-for-windows/git-for-windows-automation#41 that not only removes that space, but also updates the still-queued deploy_x86_64 Check Run.

[dscho]

The only problem I see is the funny space

I have a fix for that, and once the workflow run completed, will push an update to git-for-windows/git-for-windows-automation#41 that not only removes that space,

That fix is here: git-for-windows/git-for-windows-automation@a2fbf72

but also updates the still-queued deploy_x86_64 Check Run.

And that was done via git-for-windows/git-for-windows-automation@6d85c38.

Now off to build openssh for i686.

[dscho]

I pushed git-for-windows/git-for-windows-automation@4796c75 which started https://github.com/git-for-windows/git-for-windows-automation/actions/runs/4436229196/jobs/7784388159, and so far it's looking good:

[dscho]

@rimrul the workflow runs seem to have worked! Could I ask you to take it from here?

[rimrul]

Yes.

[rimrul]

/add relnote Comes with OpenSSH v9.3p1

[dscho]

/add relnote Comes with OpenSSH v9.3p1

The response was:

Ignoring slash command /add relnote Comes with OpenSSH v9.3p1 in #92 (comment)

The reason is that this command requires a type (feature, bug or blurb): https://github.com/git-for-windows/gfw-helper-github-app/blob/961ebdb613062545d06d1479f06d2f927e0ec646/GitForWindowsHelper/slash-commands.js#L482

The app should probably respond with an error message in a new issue comment, I guess...

[rimrul]

/add relnote feature Comes with OpenSSH v9.3p1

The workflow run was started

[rimrul]

The app should probably respond with an error message

Yes, that would be helpful. I have ideas for a PR, but probably won't get around to that before saturday or sunday.

[dscho]

@rimrul I added a ticket to make sure that this is not forgotten.