feat: Use elaborate errors value from API response if available

[whisperity]

This patch turns a "validation error"
(https://docs.github.com/en/rest/using-the-rest-api/troubleshooting-the-rest-api#validation-failed) such as a "too long description" into an understandable "too long description" issue in the CI logs, instead of a simple "Validation failed" print-out.

Uses the corresponding structure from gh api:

{
  "message": "Validation Failed",
  "errors": "Validation failed: Description is too long (maximum is 140 characters)",
  "documentation_url": "https://docs.github.com/rest/commits/statuses#create-a-commit-status",
  "status": "422"
}

[daltonbr]

Thanks for this, and sorry for the long wait.

Context: this fork exists because upstream hasn't cut a release since v2.0.1, and I've since added a source-only contribution policy that your PR predates. Apologies for the moving target.

Worth being upfront about where that policy comes from, since it's the reason the fork exists at all. I'm fairly new to JavaScript tooling, and what struck me while looking at how Actions are shipped is that dist/index.js is a single minified line of roughly a megabyte, and it is the file the runner actually executes. A change to it cannot meaningfully be reviewed. That makes it a natural hiding place for a supply-chain problem, and reviewing the source while waving the bundle through would be a formality. So the rule is that the bundle is rebuilt from source that has been read, and a workflow does it rather than a person. This applies to me as much as to anyone contributing.

Rather than send you back to do something mechanical, I pushed a commit to your branch that drops dist/index.js and the version bump:

• dist/ is generated here, and a workflow rebuilds and commits it after merge. It also happened to be the only conflicting file, so removing it cleared the conflict outright.
• The version bump would have made the release workflow abort with "Version not changed", since development is already at 3.0.2 (published today). Versions get set at release time.

Your src/main.ts change is untouched, and the PR now shows exactly that and nothing else. It's the part I wanted, and it stays yours.

Shipping it as v3.1.0.

One small thing I noticed while reading it, which I'll handle in a follow-up PR so it doesn't disturb this one: @octokit/request-error isn't declared in package.json, so the import resolves only because npm hoists it out of @actions/github. Since RequestError is used purely as a type, import type plus a devDependencies entry makes it robust against any future restructuring.
Nothing wrong with your change, just tidying.

[whisperity]

Hey! Sorry, I was on a vacation and did not have a computer with me. It's all fine, let's see how #7 evolves this further.

Not bumping dist/ means that the change isn't testable in a CI environment (by providing an explicit @branch on the uses: key), but I guess it's okay not to bump dist/ when a PR is merged, even if the original PR contained a build at some point for testing the thing out.

[daltonbr]

No worries at all, hope the vacation was good!

Fair point about testing, and you're right that leaving dist/ out of the PR means you can't point uses: at the PR branch directly. What I'd suggest for next time: keep a separate branch in your fork that has the built dist/ committed, point your test workflow at that branch, and open the PR from a branch without it. That way you can test the real thing and the PR stays source-only. I'm adding a note about this to CONTRIBUTING.md so the next person doesn't have to work it out. That's the intention, at least. This whole source-only setup is new for this repo, so let's see how it goes in practice.

As for #7: it's a follow-up to your change, not a rewrite. It drops the @octokit/request-error import in favour of reading response.data.errors directly. It also fixes one edge case: if data is null, the error handler threw a TypeError instead of reporting the error. It adds the repo's first tests too. Your message improvement works exactly the same. It'll go out in the next release (v3.1.0) along with a rebuilt dist/.

Thanks again for the patch!

[daltonbr]

@whisperity quick update: #7 is merged, and your change shipped in v3.1.0. Use @v3, or pin daltonbr/set-commit-status-action@d406aa91fdad4a523a6188b77b5e4b762008fbb1 # v3.1.0. Thanks again!