Project Management Automation: Tolerate duplicate milestone

[aduth]

Related (possibly blocks): #20009

This pull request seeks to resolve an issue where the milestone assignment automation will fail to assign the milestone to a pull request when attempting to create the milestone would result in a duplicate milestone error. Prior to #17080, a duplicate milestone was considered tolerable. If the milestone already exists, it simply proceeds to assign the milestone. However, since this milestone creation would throw an error in the new JavaScript implementation, there was no chance for the task to recover to proceed to assigning the milestone.

With these changes, a thrown error is tolerated within the task, as long as it represents an error from a duplicate milestone.

Note: A possible future refactoring to this task could try to fetch the milestone first, and only if determined to not exist, proceed to create the milestone.

Testing Instructions:

This can only be tested once merged, confirming that a milestone is assigned.

[aduth]

The task is still failing, despite this having intended to fix it.

https://github.com/WordPress/gutenberg/runs/423919172?check_suite_focus=true

I think the issue is that the code property is not actually part of the error instance, but rather passed along from the message reported in the response body of the API request.

https://developer.github.com/v3/#client-errors

It's also noted to be deprecated:

Deprecation: [@octokit/request-error] error.code is deprecated, use error.status.

(Not sure exactly what they mean by deprecated here, if it doesn't work at all)

I should also plan to follow-up at some point with additional unit tests here, to try to cover these scenarios rather than playing "Guess and Check" with the merges 😅 (though the existing test setup requires some manual mocking which would be equally as easy to mess up)

[epiqueras]

error.code and error.status are the HTTP error code.

We need to read the response body.

[aduth]

Based on some further digging, we should be able to read an errors property from the error object.

See also:

• https://github.com/octokit/rest.js/issues/684
• https://github.com/octokit/request.js/blob/2a1d768/src/fetch-wrapper.ts#L79-L80

I expect it would be the same as if we were to parse the response ourselves.

Pull request at: #20014