Due to the limitations imposed by by using both `pull_request_target` and `issue_comment` events to trigger the
"Manage PRs" workflow, the PR diff used for the validation is procured via a GitHub API request.
It is necessary to check that the pull request state matches that of the diff, which is achieved via the `sha` parameter
of the GitHub API request used to merge. This can not be determined from the `github` context provided by GitHub Actions
to the workflow for either of the trigger events, so the pull request metadata is requested from the GitHub API at the
same time as the diff.
This situation requires different handling by the `merge-fail` job. Fortunately, the two failure causes result in
different values from the merge request workflow step's `status` output.
Previously, the "Manage PRs" workflow made a comment suggesting to resolve the merge conflict after any failure to merge
a pull request. This comment is worded in a way that makes it somewhat applicable to other causes, but still might cause
the submitter to waste time unnecessarily trying to figure out how to merge a nonexistent merge conflict when the failure
had a different cause.
The 405 response is not specific to a failure due to merge conflict, but I believe that all failures due to merge
conflict will result in a 405. This means that the check is not perfect, but will make spurious mentions of merge
conflict resolution less likely at least.
A review is requested from a maintainer any time the merge fails, so they will be able to investigate and provide
assistance if necessary.
This library is being removed from Library Manager by Arduino due to security concerns.
Although there are no concerns about the library code itself, the library.properties metadata file contains an unfortunate typo in the `url` field. This causes the "More Info" link provided by the Library Manager to take the user to a misspelling of github.com owned by a typo squatter. The library author has already corrected this error, but there has not been a release of the library in the ~4 years since that time, and no response to an inquiry about the situation made ~3.5 years ago.
This was surely an honest mistake, without any malicious intent on the library author's part, but we need to resolve the situation. We will be happy to add the library back once the library maintainer has done the following:
- Create a new release or tag in the library's repository with the corrected `url` value.
- Delete the `1.0` tag that has the bad URL from the library's repository.
Add Bluepad32 library for Arduino to registry.
This library adds Bluetooth gamepad support for Arduino boards.
The boards must have a NINA co-processor.
When possible, if problems are detected in a pull request, the bot will attempt to guide the PR author through the
process of making a valid submission, which should be handled in a completely automated fashion on our end.
It has become clear that we need to prevent the removal of the final newline from `repositories.txt`. The existing system
did not accomodate this requirement. Submissions are validated on a per-library basis, and the bot comments based on
identifying which library the problem applies to. But this newline removal is not necessarily related to any specific
item added to the list. So handling for general problems with a submission PR is needed, which is added here.
Because the PR author is more likely to require assistance with resolving this sort of problem, PR review from a
maintainer is requested.
The workflow result might indicate either that the PR author could require assistance from a maintainer or that something
is wrong with the system. In this case, the situation is brought to the attention of the maintainers by requesting a pull
request review from them.
Due to the need to avoid requesting review from a maintainer when they are the PR author (which is not allowed and thus
would result in a spurious workflow failure), the code for requesting this review is not as trivial as might be expected.
Previously, this code was duplicated at multiple places in the workflow, and would become more so as additional code is
added. The workflow is made cleaner by moving that duplicated code to a single dedicated job, which is facilitated by the
recent reworking of the workflow structure.
This is a pure refactoring and should have no effect on the workflow behavior.
Whenever the bot needs to communicate to the user about a blocking issue with their pull request that they are able to
resolve, a standardized prefix is added to the situation-specific error message ("❌ **ERROR:**") to draw their
attention to this information. This standardized text occurred multiple times in the workflow, which might lead to it
becoming inconsistent over time, or just more work to improve the text. Use of an environment variable ensures that all
uses of the prefix will be consistent and allows it to be edited once in a single place.
